Предметная область – область конкретной практической деятельности. В крупных организациях обычно выделяют ряд предметных областей в рамках основных служб, в каждой из которых создаются свои базы данных для решения своих задач.
Структурирование – это введение соглашений о способах представления данных. Это понятие близко к понятиям модель данных и формализация данных. В реляционных базах данных используются три структуры данных: таблица, запись, поле. Каждая из этих структур имеет свои свойства, описываемые параметрами. Таблица имеет имя и состоит из записей. Запись имеет номер в таблице и состоит из полей. У каждого поля есть имя, тип (текстовый, числовой и т. п.), длина в байтах. Поясним эти структуры на примере построения информационной модели конкретной предметной области.
Пусть нас интересует проблема учета всех затрат предприятия, например, строящего фабрику. Затраты должны учитываться по объектам, по видам работ и по организациям-подрядчикам. В соответствии с нашими интересами построим таблицы:
Объекты [Код об, Объект],
Работы [Код раб, Работа],
Организации [Код орг, Организация, Индекс, Город, Адрес, Телефон, Факс, Эл почта]
и собственно таблицу для учета затрат
Затраты [Код затр, Затрата, Код об, Код раб, Код орг, Дата, Стоимость].
Каждая из этих таблиц имеет имя, выделенное полужирным курсивом, и состоит из записей - строк, состав которых (перечень полей) указан в квадратных скобках. Имена полей – это имена столбцов таблицы. Курсивом выделены имена ключевых полей. Значение ключевого поля (ключа) однозначно определяет запись в таблице. По возрастанию значений ключа СУБД сортирует записи в таблицах.
Ключевые поля служат также для связывания таблиц. Например, таблица Затраты может содержать множество записей, в которых указан код одной и той же организации-подрядчика. Предположим, одна и та же организация проектировала и строила мост, подъездную дорогу, трансформаторную подстанцию и, возможно, другие объекты. При обработке записей таблицы Затраты может потребоваться факс этой организации – его легко найти в таблице Организации, которая должна содержать единственную запись с требуемым нам кодом организации в поле Код орг. Связь между этими таблицами называется связью «один ко многим» (1 ® ¥): ссылка на одну запись в таблице Организации содержится во многих записях таблицы Затраты. Если бы мы ввели еще одну таблицу – Банковские реквизиты, в которой для каждой организации-подрядчика указали бы ее код, название банка, номера счетов и другие данные, используемые при оформлении платежей, то связь между этой таблицей и таблицей Организации была бы связью «один к одному» (1 ® 1), т. к. в этих таблицах есть только по одной записи с одним и тем же значением ключевого поля Код орг. В некоторых ситуациях ключ может состоять из двух-трех полей и тогда он называется составным. Например, подразделение может идентифицироваться номером цеха и номером бригады в данном цехе.
Для ключевого поля СУБД строит индекс – вспомогательную таблицу, содержащую для каждого значения ключа адрес записи в основной таблице. Поэтому, если требуется запись с определенным значением ключа, то она легко находится по индексу. Если же в таблицу вставляется новая запись, то сортировке подвергается только индекс, но не записи таблицы.
Итак, в нашем примере база данных охватывает несколько взаимосвязанных таблиц «объекты-свойства». Такие базы данных называются реляционными. Это понятие (relation – отношение) было введено известным американским специалистом в области систем управления базами данных . В 1994 г. отмечалась 25 годовщина с того момента, как (тогда научный сотрудник корпорации IBM) предложил реляционную модель. Тем не менее первая коммерческая реляционная СУБД, названная Oracle [10], появилась только в 1979 г. Она была разработана небольшой компанией Silicon Valley. Сегодня это Oracle Corporation – крупнейший в мире поставщик реляционных СУБД и сопутствующих программных продуктов. Первой СУБД клиент/сервер стал выпущенный в 1985 г. Oracle 5. В настоящее время широкое распространение получили более поздние реляционные СУБД, созданные корпорациями Oracle, Sybase, Microsoft и некоторыми другими. Современные ведущие реляционные СУБД сочетают реляционную модель данных с технологией клиент/сервер и с объектно-ориентированным подходом к созданию программных средств.
Важнейшим достоинством концепции баз данных (в отличие, например, от обработки данных в автономных файлах) является введение набора стандартных структур, в которые, как в контейнеры, вкладываются данные. Планируя работу с данными в конкретной предметной области, после уяснения основных задач решают вопросы организации данных: как сгруппировать данные в таблицы, какие поля и каких типов, предусмотреть в каждой таблице, как связать таблицы друг с другом и т. п. Решение этого комплекса вопросов называют построением информационно-логической (инфологической) модели, которая отражает предметную область в виде совокупности информационных объектов и их структурных связей.
Только после решения вопросов организации данных приступают к разработке приложений – многофункциональных программ, осуществляющих преобразования данных путем их извлечения из одних таблиц, проведения расчетов и размещения результатов в других таблицах базы данных. Такой подход, во-первых, гарантирует, что каждый новый фрагмент данных, полученный предприятием, окажется «на своем месте» - в конкретной таблице конкретной базы данных, а, во-вторых, отпадает необходимость в разработке огромного числа процедур обработки данных. Последнее объясняется тем, что типовые операции над содержимым структур данных (таблиц, записей, полей) уже запрограммированы и входят в состав СУБД – ведь системы управления базами данных как раз и предназначены для создания баз данных и последующего манипулирования этими данными. СУБД, работающую со структурами данных, можно сравнить с техническими средствами на современном транспорте – они работают с контейнерами, не зависимо от того, что в этих контейнерах перевозится в конкретном случае.
5.2. Нормализация отношений (таблиц) и обеспечение целостности данных в реляционной базе данных
В терминологии реляционных баз данных таблицы называют отношениями – ведь, включая в записи таблицы определенные поля, мы устанавливаем отношения между информационными объектами. Поскольку одни и те же данные можно по-разному сгруппировать в таблицы, то требуются некоторые правила, оптимизирующие группировку полей - свойств объектов. Такие правила были сформулированы применительно к реляционным базам данных. Это правила нормализации отношений.
Нормализация отношений – формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых данных, уменьшает трудозатраты на их ввод и корректировку. выделены три нормальные формы отношений и предложены методы преобразования отношений к третьей, самой совершенной нормальной форме.
Отношение считается нормализованным, или приведенным к первой нормальной форме, если все его атрибуты (свойства объектов, описываемые в полях записей) простые, т. е. далее неделимы. Отношение Организации (см. подраздел 5.1) можно считать приведенным к первой нормальной форме. Единственный его атрибут, который теоретически еще можно разделить на части, - это Адрес. Но практически этот атрибут уже не делим, так как улица и дом, где расположена каждая организация, нам не могут потребоваться в отдельности. А такие атрибуты, как Город, уже отделены от адреса. Так что, если нам потребуется какая-нибудь сводка по организациям-подрядчикам, расположенным в определенном городе, то мы легко сможем отобрать соответствующие записи.
Отношение находится во второй нормальной форме, если оно приведено к первой нормальной форме, и его каждый неключевой атрибут функционально зависит от ключа. Функциональная зависимость от ключа означает, что в экземпляре информационного объекта (в записи таблицы) конкретному значению ключа соответствует определенное значение описательного атрибута. Так, в таблице Затраты нашего примера коду (например, номеру) каждой затраты соответствует ее название, код объекта, в который вложены средства, коды вида работ и организации-подрядчика, дата и сумма платежа. Перечисленные атрибуты функционально зависят от ключа Код затр. Если бы ключ был составным, то для приведения отношения ко второй нормальной форме потребовалась бы функционально полная зависимость атрибутов от ключа. Она заключается в том, что каждый неключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости [6]. Транзитивная зависимость наблюдается, если один из атрибутов зависит от ключа, а другой – от этого атрибута. Например, если в таблицу Затраты включить не только код организации, но и город, в котором она расположена, то получится, что атрибут Код орг функционально зависит от ключа Код затр , а атрибут Город зависит, в свою очередь, от атрибута Код орг и, следовательно, транзитивно зависит от ключа.
Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Если бы мы включили в записи таблицы Затраты не только код организации-подрядчика, но и ее атрибуты (название, адрес и др.), то отношение уже не находилось бы в третьей нормальной форме, а это резко осложнило бы работу с базой данных. Во-первых, во все записи таблицы Затраты, где в качестве подрядчика выступает эта организация, пришлось бы вводить не только ее код, но и длинные названия, дублируя их многократно. Во-вторых, в случае изменения адреса, факса или другой характеристики организации пришлось бы вносить коррективы не в единственную запись таблицы Организации, а во множество записей таблицы Затраты.
Приведенный пример показывает, что казалось бы теоретическое понятие нормализации отношений играет важную практическую роль, позволяя устранить дублирование данных, облегчить их ввод и корректировку в базе данных. Другое важное понятие – обеспечение целостности данных в базе данных. Этот термин подразумевает, что в СУБД должны иметься средства, не позволяющие нарушать корректность и полноту хранимой информации. Например, СУБД обычно содержат средства поддержания ссылочной целостности. Так, если мы попытаемся в запись таблицы Затраты ввести код объекта 777, а в таблице Объекты еще нет объекта с кодом 777, то СУБД должна воспрепятствовать нашему намерению, если, конечно, мы выбрали соответствующий режим ее работы. Кроме того, когда мы вводим новую запись, СУБД проверяет уникальность ее ключа, обеспечивая целостность таблицы. Наконец, СУБД проверяет целостность домена. Домен – это множество допустимых значений столбца. Так в столбец Код орг могут входить только целые числа. Если при вводе записи введем в поле Код орг хотя бы одну букву или действительное число, запись не будет включена в таблицу.
Предшествующее изложение основных сведений о реляционных базах данных иллюстрировалось на примере базы данных Затраты предприятия. Предлагаемая далее лабораторная работа посвящена созданию и использованию этой базы данных с помощью СУБД Access.
5.3. Лабораторная работа: создание и использование базы данных «Затраты»
1. Создание базы данных
Сначала создадим пустую базу данных “Затраты”. Для этого откроем приложение Access, выберем пункт меню Файл/Создать, в открывшемся диалоговом окне подтвердим желание создать новую БД нажатием кнопки Ok. После этого откроется стандартное диалоговое окно Сохранить как. В нем надо выбрать каталог для размещения новой базы данных и дать имя файлу, например, Затраты.mdb. Этот файл будет содержать описание структуры таблиц, сами таблицы, формы, запросы и отчеты, которые будут созданы в рамках базы данных “Затраты”. На рис. 5.1 показано окно приложения Access. В этом окне после создания пустой базы данных “Затраты” появится окно базы данных с заголовком “Затраты: база данных”, только в этом окне еще не будет перечня таблиц и, конечно, в окне приложения Access еще не будут открыты окна таблиц для просмотра и корректировки наших четырех таблиц (см. подраздел 5.1). На рисунке эти таблицы показаны заранее, чтобы читатель яснее представлял то, что еще предстоит создать.
2. Создание таблиц базы данных, ввод данных во вспомогательные таблицы
Теперь, когда пустая база данных существует, создадим пустые таблицы, т. е. пока только определим их структуру – опишем каждое поле записи. Начинать надо со вспомогательных таблиц Объекты, Работы и Организации. Для создания таблицы Объекты в окне базы данных выберем тип объектов, с которыми собираемся работать, а именно – Таблицы. Теперь нажмем кнопку Создание таблицы в режиме конструктора. В открывшемся диалоговом окне (Рис. 5.2) сначала создадим таблицу Объекты (на рисунке – слева, внизу). В графе Имя поля введем Код об, а в поле со списком Тип данных выберем Числовой. После этого в поле со списком Размер поля выберем Целое. Затем, нажав на панели инструментов кнопку с изображением ключа, сделаем поле Код об ключевым. Теперь определим второе поле – поле Объект. В графу Имя поля введем его название, а в поле со списком Тип данных выберем Текстовый. Длина текстового поля по умолчанию равна 50 байтам, и это нас устраивает. После этого окно, в котором мы определяли поля таблицы Объекты, можно закрыть с помощью кнопки системного меню (в строке заголовка окна, справа). При закрытии этого окна появится диалоговое окно, в котором надо задать имя таблицы – “Объекты”. Теперь таблица создана, ее можно открыть с помощью кнопки Открыть в окне базы данных и ввести в нее записи (см. рис. 5.1). Сразу после создания можно ввести большую часть записей во вспомогательные таблицы. Основная таблица Затраты будет пополняться очень долго.
Рис. 5.1. Рабочее окно СУБД Access с открытыми таблицами БД «Затраты»
Для ввода данных в таблицу надо “встать” в нужное поле с помощью щелчка мыши или с помощью клавиш перемещения курсора и вводить данные в это поле. После ввода значения нажимают клавишу <Enter> – этим завершается ввод данных в ячейку таблицы, и курсор перемещается в следующее поле записи или в первое поле очередной записи. Для перемещения курсора также можно пользоваться клавишами <Tab> и <Shift>+<Tab>. Кроме того, перемещаться по записям таблицы помогает навигатор – линейка с кнопками внизу каждой таблицы (см. рис. 5.1).
Рис. 5.2. Создание таблиц Объекты и Затраты
Таблицы Работы и Организации создаются точно так же, как таблица Объекты, только в таблице Организации больше полей.
3. Создание основной таблицы
Создание таблицы Затраты (см. рис. 5.2 – справа, внизу) требует дополнительных пояснений по поводу определения полей Код об, Код раб, Код орг. Каждое из этих полей необходимо определить как поле со списком. На рис. 5.2 показано, как это сделано для поля Код об. После определения типа этого поля (числовой) и уточнения его общих параметров (целое) с помощью вкладки Общие, переходим на вкладку Подстановка – она показана на рисунке справа, внизу. Здесь в полях со списком выбираем тип элемента управления (Поле со списком), тип источника строк (Таблица или запрос), источник строк (таблица Объекты), присоединенный столбец (первый) и число столбцов в списке (2). Надо указать также ширину столбцов и списка, например, 1; 7 см – столбцы, 8 см – весь список. Теперь при вводе данных в поле Код об (прямо в таблицу Затраты или с помощью формы – рис. 5.3) можно не вспоминать коды объектов, а выбирать их из списка, в строках которого содержатся и коды и названия. Ведь мы включили в список поля Код об таблицы Затраты два столбца из таблицы Объекты, причем полю Код об таблицы Затраты соответствует именно первый (присоединенный) столбец таблицы Объекты. Для того чтобы список появился (см. рис. 5.1), надо просто щелкнуть мышью по стрелке у правого края поля Код об. Таким образом, Access предоставляет удобные средства для ввода и корректировки данных. Но еще удобнее для ввода данных в таблицу с большим числом полей использовать форму (см. форму Затраты на рис. 5.3). Созданию формы должно предшествовать создание схемы данных.
4. Создание схемы данных
Для создания схемы данных можно воспользоваться пунктом меню Сервис/Схема данных или соответствующей кнопкой на панели инструментов. В появившемся диалоговом окне надо выбрать таблицы, включаемые в схему. После этого появится схематическое изображение таблиц в виде прямоугольников, содержащих список полей (см. рис. 5.3). После этого остается с помощью мыши соединить поля Код об, Код раб, Код орг таблицы Затраты с ключевыми полями других таблиц – на схеме появятся стрелки с указанием типа связи (см. подраздел 5.2). Если по стрелке щелкнуть правой клавишей мыши, то всплывет меню, позволяющее изменить свойства связи: например, можно, выбрав метод Изменить связь, установить в очередном диалоговом окне флажок Обеспечение целостности данных (см. подраздел 5.2). На рис. 5.3 схема данных изображена не в момент ее создания, а при создании запроса – схема данных используется всегда, когда данные берутся из нескольких связанных таблиц.
|
Формирование или корректировка запроса в режиме конструктора
5. Создание формы
На рисунке 5.3 форма Затраты изображена справа, вверху. Если в таблице мы видим сразу много записей, то в форме видны поля только одной записи, но зато сразу видны все поля – даже если запись очень длинная. Кроме того, в форму Затраты можно включить поля не только из таблицы Затраты, но и из других таблиц, если, например, мы хотим видеть в форме не только коды (объекта, вида работ, организации), но и соответствующие названия (см. рис. 5.3). Для этого и потребовалось перед созданием формы создать схему данных.
Для создания формы Затраты в окне базы данных выберем тип объекта – Формы и нажмем кнопку Создание формы с помощью Мастера. После этого откроется диалоговое окно, позволяющее выбирать таблицы (или запросы), а из них – поля, включаемые в форму. Далее форма создается автоматически, почти без участия пользователя. При вводе данных с помощью формы для перехода к очередной, предыдущей, к первой или последней записи таблицы используется навигатор – как и при работе с таблицей. Важно понимать, что форма – это не самостоятельный информационный объект, а только удобный способ визуализации записей таблиц, ввода в них данных и их корректировки. Конструкцию формы можно изменить после ее создания – в режиме конструктора. Например, поля Объект, Работа, Организация можно передвинуть, поместив их рядом с соответствующими кодами, справа от них.
6. Создание запросов
Запросы создаются с целью отбора данных из таблиц по некоторым критериям. Например, создадим запрос Затраты за период, содержащий данные о затратах за любой период, который выберет пользователь с помощью параметров Дата1 и Дата2. Чтобы создать запрос, в окне базы данных выберем тип объекта – Запросы и нажмем кнопку Создание запроса с помощью конструктора. В следующем диалоговом окне выберем таблицы, из которых собираемся отбирать данные, и получим окно, изображенное на рис. 5.3, внизу. В этом окне в полях со списками Имя таблицы и Поле надо выбрать поля, включаемые в запрос, ниже можно выбрать вариант сортировки записей и указать условия их отбора. Закрыв окно, можно запомнить созданный запрос. При его просмотре мы видим виртуальную таблицу (представление [10]), включающую только те данные, которые мы отобрали. Если изменить данные в исходных таблицах, то результат просмотра запроса также изменится.
Результаты запроса удобно использовать в качестве источника информации для составления отчета.
7. Формирование отчетов
На рис. 5.4 показан отчет Затраты по объектам за первый квартал 1998 года. В этот отчет включены данные из запроса Затраты за период. Отчет получен с помощью мастера отчетов. В окне базы данных надо выбрать тип объекта – Отчеты и нажать кнопку Создать отчет с помощью мастера, далее выбрать запрос Затраты за период – в качестве источника данных. После этого, делая выбор в предлагаемых диалогах, остается уточнить перечень полей, включаемых в отчет, вариант группировки и сортировки записей, вариант вывода итоговых строк и ориентацию страниц. Отчет в сочетании с запросом позволяет отобрать из базы данных требуемую информацию, сгруппировать итоговые записи (на рис. 5.4 группировка выполнена по объектам) и автоматически получить итоговые строки. Отчет можно напечатать, выбрав пункт меню Сервис/Связи с Office/Публикация в Microsoft Office Word. Наконец, в отчет нетрудно внести редакционные изменения, но не в режиме создания с помощью мастера отчетов, а в режиме конструктора. Так в нашем примере слово Sum, которое процедура Мастер отчетов вставляет в итоговые строки, заменено на слово Сумма. Вообще в режиме конструктора можно изменять и таблицы, и формы, и запросы, и отчеты.
Лабораторная работа «Затраты» должна дать начальные навыки в области создания и последующего использования баз данных. В частности, эта лабораторная работа иллюстрирует правильную последовательность действий – пункты 1-7. Создание «украшений» базы данных, вроде кнопочной формы, легко освоить самостоятельно, используя пункт меню Сервис/Служебные программы/Диспетчер кнопочных форм. Впрочем, подобные «украшения» в большинстве случаев совершенно бесполезны. Иногда их применяют, чтобы «спрятать» от пользователя всю внутреннюю структуру базы данных – даже таблицы. А это уже вредно и характерно для разработчиков, не сотрудничающих со специалистами в предметной области (пользователями базы данных), а относящихся к ним с неоправданным высокомерием.
Дальнейшему развитию навыков в области создания баз данных должны способствовать самостоятельные работы, предлагаемые в следующем подразделе.
Рис. 5.4. Типичный вид отчета, получаемого с помощью СУБД Access
5.4. Самостоятельные работы по созданию баз данных
Приведенные ниже самостоятельные работы могут быть использованы как курсовые. В этом случае, кроме базы данных в файле *.mdb, подготавливается пояснительная записка к базе данных в виде файла *.doc. Требования к ее оформлению – такие же, как требования к оформлению самостоятельной работы по текстовому процессору Word (см. подраздел 3.6). Что касается содержания пояснительной записки, то не надо копировать в нее из Интернета и всевозможных пособий общие сведения по базам данных – требуется краткое и ясное описание своей базы данных: сформулировать ее назначение, перечислить задачи, которые она позволяет решать, описать таблицы и схему данных. Один раздел надо посвятить формам, запросам и отчетам, рассматриваемым в соответствующих подразделах. Желательно также, чтобы в пояснительной записке было введение, заключение и список литературы – соответствующие заголовки оформляются, как и названия разделов, в стиле заголовка первого уровня.
Кроме создания баз данных, для студентов, интересующихся программированием, в качестве курсовых могут быть предложены работы, приведенные в разделе 11 пособия [6].
Состав самостоятельной работы по созданию базы данных
Самостоятельная работа на создание и применение базы данных должна включать в себя:
1) Создание в режиме конструктора таблиц, указанных в варианте задания. Сначала рекомендуется создавать вспомогательные (справочные) таблицы, затем основные. В основных таблицах обязательным является использование полей со списками для ссылок на объекты, коды которых образуют ключевые поля вспомогательных таблиц.
2) Создание схемы данных, установление связей между таблицами.
3) Создание форм для облегчения работы с основными таблицами.
4) Ввод данных в таблицы: во вспомогательные – не менее чем по 5 записей, в основные – не менее чем по 15 записей.
5) 1-2 запроса для базы данных; их надо спроектировать, используя "Конструктор" и задавая условия отбора параметрами, а не значениями. В качестве условий отбора в большинстве случаев подходит период времени (см. лабораторную работу «Затраты»).
6) 1-2 отчета по созданной базе данных; источником данных для отчета может быть соответствующий запрос; записи в отчете д. б. сгруппированы; если в записях есть числовые поля, то для каждой группы данных в отчет д. б. включена итоговая строка (сумма или минимальное и максимальное значения).
Критерии оценки работ
Максимальная оценка (50) баллов уменьшается на 5-10 баллов в каждом из следующих случаев:
1) Неэффективно определены типы и длины полей в записях таблиц, или же неправильно заданы значения по умолчанию. Например, код жанра определен как счетчик (длинное целое), а количество жанров очень невелико и для их кодирования достаточно одного байта. Или для ключевого поля задано значение по умолчанию, а, например, для даты продажи (отправки, выдачи) значение по умолчанию – текущая дата Date( ) – не задано.
2) Поля, содержащие ссылки на записи вспомогательных таблиц, не являются полями со списками или списки не удобны для работы с ними, например, не задана ширина столбцов. Ошибкой считается также использование SQL-запроса в качестве источника информации для формирования списка, когда это совсем не требуется – скажем, в список включаются первые два поля из одной таблицы. SQL-запрос применяется для формирования списка, если поля, образующие записи списка, надо извлекать из разных таблиц, или из одной, но это не первые, идущие подряд поля этой таблицы. Часто встречается еще одна ошибка: разработчик базы данных пытается скрыть от пользователя коды объектов, на которые ссылается основная таблица, показывая только названия. Между тем, именно пользователь обычно разрабатывает системы кодирования, и именно коды являются рабочим механизмом, связывающим таблицы. А вот в конечные документы – в запросы и отчеты – включаются как раз названия, а не коды.
3) Количество записей в таблицах не соответствует требованиям.
4) Отсутствует схема данных или в ней не установлен контроль ссылочной целостности (см. подраздел 5.2).
5) Отсутствует форма для ввода данных в основную таблицу или эта форма неудобна для ввода и просмотра данных. Например, для удобства просмотра записей в форму рекомендуется, кроме кодов в виде полей со списками, включать названия (но не заменять ими коды) – см. базу данных «Затраты».
6) Отсутствуют запросы для решения задач, либо запросы не является параметрически универсальными или содержат ошибки. Условия отбора записей должны задаваться в запросе параметрами, например, >= [Год1] AND < [Год2], а не значениями этих параметров: >= 1990 AND < 2008.
7) Отсутствуют отчеты или отчеты не содержит группировки данных и (или) итоговых строк по группам данных – см. рис. 5.4.
Далее приводятся варианты заданий. Выбор варианта – по согласованию с преподавателем.
Варианты самостоятельных работ
Вариант 1. База данных "Делопроизводство"
Основные таблицы:
Входящие [Вх_номер, Код_типа, Документ, Код_орг, Исх_номер, Отправитель, Дата_отпр, Код_отд, Получатель, Дата_получ]
Исходящие [Исх_номер, Код_типа, Документ, Код_отд, Отправитель, Дата_отпр, Код_орг, Получатель]
Вспомогательные таблицы:
Типы документов [Код_типа, Тип_док]
Организации [Код_орг, Организация, Индекс, Город, Адрес, Телефоны, Факс, Эл_почта]
Отделы [Код_отд, Отдел, Начальник, Телефоны]
В основных таблицах регистрируются входящие и исходящие документы; типом документа может быть письмо, счет, акт, проект, отчет и т. п.; поле Документ содержит название документа, поле Организация - название организации, поле Отдел - название отдела; под адресом организации понимается улица и номер дома.
Вариант 2. База данных "Архив предприятия"
Основные таблицы:
Документы [Арх_номер, Документ, Код_типа, Код_объекта, Код_орг, Осн_автор, Год, Стр, Экз]
Журнал [Номер_записи, Арх_номер, Номер_экз, Код_отд, Сотрудник, Дата_выдачи, Дата_возвр]
Вспомогательные таблицы:
Типы документов [Код_типа, Тип_док]
Объекты [Код_об, Объект]
Организации [Код_орг, Организация, Индекс, Город, Адрес, Телефоны, Факс, Эл_почта]
Отделы [Код_отд, Отдел, Начальник, Телефоны]
В таблице Документы регистрируются документы, поступающие на хранение в архив; для каждого документа указывается его архивный номер, название, код типа, код объекта, которому посвящен документ, код организации, в которой подготовлен документ, фамилия основного автора, год создания документа, число страниц в нем и количество экземпляров в архиве. В таблице Журнал регистрируется выдача и возврат каждого экземпляра каждого документа с указанием кода отдела, в который выдан документ, и фамилии сотрудника; типом документа может быть письмо, счет, акт, проект, отчет и т. п.
Вариант 3. База данных "Домашняя библиотека"
Основные таблицы:
Книги [Номер_книги, Название, Код_жанра, Код_темы, Код_издательства, Автор, Год, Стр, Шкаф, Полка]
Журнал [Номер_записи, Номер_книги, Кому_дана, Дата_выдачи, Дата_возвр]
Вспомогательные таблицы:
Жанры [Код_жанра, Жанр]
Темы [Код_темы, Тема]
Издательства [Код_изд, Издательство, Страна, Город]
В таблице Книги регистрируются книги домашней библиотеки. Таблица Журнал предназначена для учета книг, данных друзьям и родственникам.
Вариант 4. База данных "Музыкальные записи"
Основные таблицы:
Произведения [Номер_произв, Название, Код_стиля, Композитор, Исполнитель, Альбом, Год, Номер_носителя]
Журнал [Номер_записи, Номер_носителя, Кому_дан, Дата_выдачи, Дата_возвр]
Вспомогательные таблицы:
Стили [Код_стиля, Стиль]
Носители [Номер_носителя, Тип_носителя, Полка]
В таблице Произведения регистрируются музыкальные записи с указанием кода стиля, композитора, исполнителя, названия альбома, года записи и номера носителя. Таблица Журнал предназначена для учета дисков и кассет (носителей), данных друзьям и родственникам. Таблица Стили содержит перечень музыкальных стилей (классика, джаз и т. п.). В таблице Носители для каждого носителя указывается тип (кассета, диск, диск MP3) и место хранения.
Вариант 5. База данных "Кадры"
Основные таблицы:
Служебные сведения [Код_сотр, Фамилия, Имя_отчество, Код_отдела, Код_должн, Образование, Код_спец, Стаж, Телефоны]
Личные сведения [Код_сотр, Дата_рожд, Место_рожд, Паспорт, Адрес, Адрес_регистр, Семейн_полож, Число_детей]
Вспомогательные таблицы:
Отделы [Код_отд, Отдел, Начальник, Телефоны]
Должности [Код_должн, Должность]
Специальности [Код_спец, Специальность]
В таблице Служебные сведения содержатся данные, которые могут каждодневно требоваться в организации, где сотрудник работает; эта таблица дополняется таблицами Отделы, Должности и Специальности. В таблице Личные сведения указываются два адреса, потому что адрес проживания может не совпадать с адресом регистрации.
Примечание: в действительности база данных "Кадры" обычно сложнее - в ней больше таблиц (воинский учет, стажировки и т. п.), а в таблицах больше полей.
Вариант 6. База данных "Спектакли"
Основная таблица:
Спектакли [Код_спект, Название, Код_жанра, Код_театра, Код_режис, Актер, Актриса, Дата выпуска, Продолжительность, Мин_цена, Макс_цена]
Вспомогательные таблицы:
Жанры [Код_жанра, Жанр]
Театры [Код_театра, Театр, Город, Адрес, Нач_спектаклей, Телефоны]
Режиссеры [Код_режис, Фамилия, Имя_Отч, Лучшие_спектакли]
В полях Актер и Актриса указываются исполнители главных ролей; в запросах можно предусмотреть поиск спектаклей определенного жанра, выпущенных в определенный промежуток времени; возможен отбор спектаклей по фамилиям исполнителей главных ролей - актера и (или) актрисы, а также поиск спектаклей, поставленных определенным режиссером; возможен отбор по цене билетов.
Вариант 7. База данных "Расходы семьи"
База данных предназначается для учета расходов семьи и получения сводок-отчетов за периоды времени, задаваемые соответствующими параметрами. В качестве основной таблицы, позволяющей решать поставленные задачи, в базу данных рекомендуется включить таблицу
Расходы [N_расхода, Дата, Назв_расхода, Сумма, Код_статьи, Код_плательщ, Код_польз]
Каждая запись этой таблицы содержит номер и дату очередного расхода (затраты), название расхода, сумму затраты, код статьи расходов, код плательщика (кто из членов семьи платил) и код пользователя (т. е. для кого что-то оплачено).
Основная таблица ссылается на вспомогательные (справочные) таблицы Статьи_расходов и Семья. В записях таблицы Статьи_расходов указывается код статьи и ее наименование, например, 1 – продукты, 2 – вино-водочные изделия, 3 – табачные изделия, 4 – одежда, 5 - обувь, 6 – оплата жилищно-коммунальных услуг и т. п. Таблица Семья должна содержать в записях, кроме кода члена семьи, как минимум, его наименование, например, 1 – вся семья, 2 – дедушка, 3 – отец, 4 – мама, 5 – Маша, 6 - Саша. Вся семья (ее общая часть бюджета) или кто-то из ее членов может быть плательщиком. Покупки также могут предназначаться для всей семьи или для кого-то конкретно.
Для удобства ввода данных в основную таблицу создайте форму Расходы. Создайте запрос, формирующий виртуальную таблицу, содержащую основные сведения о расходах за указанный с помощью соответствующих параметров период времени. В эту таблицу можно включить дату, название статьи расхода, имена плательщика и пользователя, а также сумму платежа. Построенный таким образом запрос может быть источником данных для отчетов. Отчеты должны позволять оценивать затраты семьи за указанный период времени. В одном из отчетов надо предусмотреть группировку данных по статьям расходов, во втором – по плательщикам, в третьем – по пользователям. По указанным группам данных должны быть сформированы итоговые строки, отражающие суммарные расходы.
Вариант 8. База данных "Видеофильмы"
Основные таблицы:
Фильмы [Код_фильма, Название, Код_жанра, Код_студии, Код_режис, Актер, Актриса, Год, Аннотация]
Журнал [Номер_записи, Код_фильма, Кому_дан, Дата_выдачи, Дата_возвр]
Вспомогательные таблицы:
Жанры [Код_жанра, Жанр]
Киностудии [Код_студии, Название, Страна]
Режиссеры [Код_режис, Фамилия, Имя, Лучшие_фильмы]
В полях Актер и Актриса указываются исполнители главных ролей; в запросах можно предусмотреть поиск видеофильмов, выпущенных в определенные годы; возможен поиск по журналу фильмов, которые были даны кому-нибудь и не возвращены.
Вариант 9. База данных "Продажи книг"
База данных предназначается для учета продаж книг в книжном магазине и получения сводок-отчетов за периоды времени, задаваемые соответствующими параметрами.
Основная таблица:
Продажи [N_продажи, Дата, Назв_книги, Автор, Код_жанра, Код_издат, Год_издания, Цена]
Вспомогательные таблицы:
Жанры [Код_жанра, Жанр]
Издательства [Код_изд-ва, Название, Город]
Каждая запись основной таблицы содержит номер и дату продажи, название книги, фамилию автора, код жанра, код издательства, год издания и цену книги. Основная таблица ссылается на вспомогательные (справочные) таблицы Жанры и Издательства. В записях таблицы Жанры указывается код жанра и его наименование, например, 1 – исторический роман, 2 – фантастика, 3 – фэнтези, 4 – детектив, 5 - поэзия и т. п. Таблица Издательства должна содержать в записях, кроме кода издательства, как минимум его название.
Создайте запрос, формирующий виртуальную таблицу, содержащую основные сведения о продажах за указанный с помощью соответствующих параметров период времени. Отчеты должны позволять оценивать стоимость продаж за указанный период времени. В одном из отчетов можно предусмотреть группировку данных по жанрам, а во втором – по издательствам. По указанным группам данных должны быть сформированы итоговые строки, отражающие суммарную стоимость продаж.
Вариант 10. База данных "Продажи препаратов"
База данных предназначается для учета продаж препаратов в аптеке и получения сводок-отчетов за периоды времени, задаваемые соответствующими параметрами.
Основная таблица:
Продажи [N_продажи, Дата, Код_преп, Код_произв, Емк_упак, Цена, Кол_упак]
Вспомогательные таблицы:
Препараты [Код_преп, Препарат, Тип_преп]
Типы_препар [Тип_преп, Наименование_типа]
Производители [Код_произв, Производитель, Страна]
Каждая запись основной таблицы содержит номер и дату продажи, код препарата, код производителя, емкость упаковки, цену упаковки и количество проданных упаковок. В запросе «Продажи за период» надо предусмотреть вычисляемое поле Стоимость: Цена*Кол_упак.
Основная таблица ссылается на вспомогательные (справочные) таблицы Препараты и Производители. В записях таблицы Препараты указывается код препарата, его название и тип. Тип задается кодом, например, 1- антибиотики, 2 – витамины, 3 – антиаллергены, 4 – от простуды и гриппа, 5 – биодобавки и т. п. Следовательно, таблица Препараты ссылается на таблицу Типы_препар.
Вариант 11. База данных "Страны Европы"
Основная таблица:
Страны [Код_Страны, Страна, Столица, Население, Площадь, Код_строя, Код_религии]
Вспомогательные таблицы:
Государственный строй [Код_строя, Гос_строй, Пояснение]
Религии [Код_религии, Религия]
В таблице Страны содержатся основные сведения о странах континента. Сведения можно выбрать из атласов или из Интернета.
Таблица Государственный строй содержит информацию об основных видах государственного строя: конституционная монархия, президентская республика, парламентская республика и т. п.; пояснение может содержать дополнительную информацию о государственном устройстве.
Для удобства ввода данных в основную таблицу создайте форму Страны. Создайте запрос, формирующий виртуальную таблицу, содержащую основные сведения о странах с определенным государственным строем. Другой запрос может быть ориентирован на отбор сведений о странах, в которых главенствует та или иная религия. В отчетах страны могут быть сгруппированы по религии или по государственному строю. По указанным группам данных должны быть сформированы итоговые строки, отражающие суммарную площадь территории и население.
Вариант 12. База данных "Страны Азии" – см. пояснения к варианту 11
Вариант 13. База данных "Страны Америки" – см. пояснения к варианту 11
Вариант 14. База данных "Страны Африки" – см. пояснения к варианту 11
ЛИТЕРАТУРА
1. , , . Лабораторный практикум по информатике. Расширенные возможности Excel.-Иркутск: Изд-во ИрГТУ. – 2003. – 71с.
2. Excel 97 в примерах. – СПб.: Питер, 1997. – 336 с.
3. Громов информационные ресурсы: проблемы промышленной эксплуатации. – М.: Наука, 1984.
4. Информатика: Учебник /Под ред. проф. . – М.: Финансы и статистика, 1997. – 768 с.
5. Справочник по математике для научных работников и инженеров. – М.: Наука, 1968. –720 с.
6. , Шишкина : Учебное пособие/Издание третье, переработанное. – Иркутск: Изд-во Иркутского госуд. технич. ун-та, 2005. – 144 с.
7. и др. Visual Basic для приложений (версия 5) в подлиннике: пер. с англ. – СПб.: BHV – Санкт-Петербург, 1998. – 704 с.
8. , , Алексеев информатика: Учебное пособие. – М.: АСТ-ПРЕСС: Инфорком-Пресс, 1999. – 480 с.
9. Microsoft Visual Basic 5. Шаг за шагом: Практ. пособ. /Пер. с англ. кн. Микаэла Хальворсона. – М.: Изд-во ЭКОМ, 1998. – 432 с.
10. Oracle 7 и вычисления клиент-сервер /Пер. с англ. кн. Стивена Бобровски. -М.: Изд-во ЛОРИ, 1996. – 651 с.
11. , , Шагун Web-документов. Лабораторный практикум по информатике.– Иркутск: Изд-во Иркутского госуд. техн. ун-та, 2002. – 39 с.
12. , , . Лабораторный практикум по информатике. Часть II. Visual Basic for Applications. – Иркутск: Изд-во Иркутского госуд. техн. ун-та, 2002. – 52 с.
13. Microsoft Office 2003. Самый полный и понятный самоучитель/ Алекс Экслер. – М.: НТ Пресс. 2008. – 400 с.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 |
