Составить программу, которая запрашивает ввод температуры тела человека и определяет, здоров он или болен (здоров при 36используйте блок схему для выполнения , а не програмные коды какие-то

ответ:

объяснение:

на одних блок-схемах далеко не улетишь

program z1; (начало программы)

var n, s, i, c: integer; (раздел описания переменных, n(кол-во чисел), s(сумма чисел), i(счетчик), с(число, введенное с клавиатуры))

begin (тело программы)

writeln ('кол-во чисел? '); (подсказка для пользавателя)

readln (n); (считывание переменной)

s: =0; (обнуляем переменную)

for i: = 1 to n do begin (цикл будет повторяться от 1 до n; т.к в цикле будет несколько действий открываем операторные скобки (begin\end), начало цикла)

writeln ('введите число');   (подсказка для пользавателя)

readln(c);   (считывание переменной)

if c> 0 then s: =s+c; (если с> 0 тогда к сумме мы прибавляем число) 

end; (конец цикла)

writeln ('сумма=',s);   (подсказка для пользавателя и ответ)

readln(s); (считывание переменной)

readln; (считывание)

end.(конец программы)

с точки зрения простоты реализации желательно любые модели представлять в виде взаимосвязанных таблиц (реляционной модели), так как рынок реляционных субд давно освоен и имеется множество методик, рекомендаций, - как это делать правильно и чтобы все быстро работало. наиболее популярен для обработки информации в таком виде язык стрктурированных запросов sql, программных продуктов, использующих различные его диалекты - тысячи.известно что существуют , плохо проектируемые в реляционных моделях, в основном связанные с тем что объекты сильно отличаются друг от друга по набору свойств. в реляционной модели в этом случае приходится делать "широкие" таблицы, содержащие исчерпывающий перечень колонок, 90% значений в которых будут пусты, либо для каждого вида объекта вводить свою таблицу, что резко снижает скорость работы с такой бд.в этом случае лучше переходить на объектно-ориентированную субд (например, cache) либо хранить данные в формате, допускающем вариации в узлах (например, в xml). скорость обработки больших массивов в этом случае ниже, но за счет того, что база становится компактной, скорость работы в целом возрастает. а в случае xml даже отпадает возможность создавать отдельное описание для структуры таблиц - формат xml несколько , зато сам себя документирует, за это его и любят.к таким неструктурированным базам тяготеют также вычислительноемкие расчеты - распознавание образов, речи, расчеты протекания процессов и реакций и пр. иногда даже такие необходимо делать в реляционной модели, чтобы ускорить расчеты определенных этапов, на которые уходит львиная доля процессорного времени.вообще это отдельная область науки, можете ознакомиться с классиков, например с "библией" реляционной модели, автор д. кнут.исходя из сказанного ответ на вопрос - в табличном виде оптимально представлять наборы объектов, одинаковыми свойствами, для которых почти все свойства используются и имеют различные значения (нет "пустот").количество таких объектов для современных баз данных может быть достаточно велико - лично я работаю с базами, содержащими миллионы записей, но при этом число различных таблиц (видов объектов с разными наборами полей) невелико и составлет от нескольких десятков до нескольких сотен.