1. Площадь документа 10 * 15 = 150 кв.см Если в 1 кв.см 600 точек, то в 150 кв.см 150 * 600 = 90 000 точек. На каждую точку отводится 4 бита, тогда всего 90 000 * 4 бит = 45 000 байт = 43,95 Кб (в 1 байте 8 бит, в 1 Кб 1024 байт)
2. Всего символов: 2000 страниц * 80 строк/страницу * 100 символов/строку = 16 000 000 На каждый символ отводится 16 бит = 2 байта, тогда всего на кодирование текста уйдёт 16 000 000 * 2 = 32 000 000 байт = 30,52 Мб (1 Мб = 1024 Кб). На изображения потребуется дополнительно 80 * 5 Мб = 400 Мб.
Общий объем рукописи 400 Мб + 30,52 Мб = 430,52 Мб < 512 Мб, рукопись поместится на флэшке.
3. V = N F I t, N - число каналов (1), F - частота (22 000 Гц), I - глубина кодирования (16 бит), t - время (120 с). V = 1 * 22 000 * 16 * 120 бит = 22 000 * 2 * 120 байт = 5156,25 Кб = 5,04 Мб
Печально, придется придумывать, а фантазия иногда ведет не в ту стпень, но не суть. Лично мне кажется что неплохо было бы хранить в БД под названием погода информацию относительно погоды, скажем гидромежцентра или как его там а значит объектами будут - температура влажность ветер дождь и тд если бы я ее проектировал то в качестве ключа выбрал бы дату, потому как она явно уникальна и прогнозы идут каждый день далее успеваемость - допустим успеваемость студента в универе, а значит неплохо бы в качестве объектов задать предметы по которым интересует успеваемость(обычно все) в качестве ключа можно взять любой уникальный идентификатор, хоть серию в паспорте хоть ИНН, но рас уж у нас универ пусть будет номер студенческого билета, или зачетной книжки и наконец факультативы - нужен перечень всех факультативов(причем не важно посещает все или не посещает ни одного), не слышал чтобы в школах были факультативы, так что предположу что учебное заведение чуть чуть повыше а значит в качестве ключа так же подойдет номер студ билета
Если в 1 кв.см 600 точек, то в 150 кв.см 150 * 600 = 90 000 точек.
На каждую точку отводится 4 бита, тогда всего 90 000 * 4 бит = 45 000 байт = 43,95 Кб (в 1 байте 8 бит, в 1 Кб 1024 байт)
2. Всего символов: 2000 страниц * 80 строк/страницу * 100 символов/строку = 16 000 000
На каждый символ отводится 16 бит = 2 байта, тогда всего на кодирование текста уйдёт 16 000 000 * 2 = 32 000 000 байт = 30,52 Мб (1 Мб = 1024 Кб).
На изображения потребуется дополнительно 80 * 5 Мб = 400 Мб.
Общий объем рукописи 400 Мб + 30,52 Мб = 430,52 Мб < 512 Мб, рукопись поместится на флэшке.
3. V = N F I t, N - число каналов (1), F - частота (22 000 Гц), I - глубина кодирования (16 бит), t - время (120 с).
V = 1 * 22 000 * 16 * 120 бит = 22 000 * 2 * 120 байт = 5156,25 Кб = 5,04 Мб
4. V = 2 * 11 000 * 16 * 360 бит = 3 * (22 000 * 16 * 120) бит = 3 * 5,04 Мб = 15,12 Мб
Лично мне кажется что неплохо было бы хранить в БД под названием погода информацию относительно погоды, скажем гидромежцентра или как его там а значит объектами будут - температура влажность ветер дождь и тд если бы я ее проектировал то в качестве ключа выбрал бы дату, потому как она явно уникальна и прогнозы идут каждый день
далее успеваемость - допустим успеваемость студента в универе, а значит неплохо бы в качестве объектов задать предметы по которым интересует успеваемость(обычно все) в качестве ключа можно взять любой уникальный идентификатор, хоть серию в паспорте хоть ИНН, но рас уж у нас универ пусть будет номер студенческого билета, или зачетной книжки
и наконец факультативы - нужен перечень всех факультативов(причем не важно посещает все или не посещает ни одного), не слышал чтобы в школах были факультативы, так что предположу что учебное заведение чуть чуть повыше а значит в качестве ключа так же подойдет номер студ билета