Министерство образования Республики Беларусь БЕЛОРУССКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Кафедра «Таможенное дело» Т.Р. Разорëнова БАЗЫ ДАННЫХ: РАЗРАБОТКА И УПРАВЛЕНИЕ Методическое пособие для выполнения курсовой работы Минск БНТУ 2011 Министерство образования Республики Беларусь БЕЛОРУССКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Кафедра «Таможенное дело» Т.Р. Разорëнова БАЗЫ ДАННЫХ: РАЗРАБОТКА И УПРАВЛЕНИЕ Методическое пособие для выполнения курсовой работы по дисциплинам «Информационные таможенные технологии» для студентов специальности 1–96 01 01 «Таможенное дело» и «Компьютерные информационные технологии» для студентов специальности 1–25 01 07 «Экономика и управление на предприятии» Минск БНТУ 2011 УДК 004.65:378.147.091.313 (075.8) ББК 32.97 я7 Р 17 Рецензенты: Л.И. Дроздович, доцент кафедры «Экономика и управление на предприятии» БНТУ, кандидат экономических наук; Н.Н. Гурский, доцент кафедры «Программное обеспечение вычислительной техники и автоматизированных систем» БНТУ, кандидат технических наук Р 17 Разорёнова, Т.Р. Базы данных: разработка и управление: методическое пособие для выполне- ния курсовой работы по дисциплинам «Информационные таможенные техноло- гии» для студентов специальности 1–96 01 01 «Таможенное дело» и «Компью- терные информационные технологии» для студентов специальности 1–25 01 07 «Экономика и управление на предприятии» / Т.Р. Разоренова. – Минск: БНТУ, 2012. – 48 с. ISBN 978-985-525-631-2. Методическое пособие содержит общие положения по выполнению курсовой работы по разделу «Базы данных: разработка и управление» в курсах «Компью- терные информационные технологии» и «Информационные таможенные техно- логии», где целью работы является создание баз данных и управление ими в сфере деятельности таможенных органов или некоторой заданной предметной области. Изложены цели курсового проектирования, тематика работ. Приведены основные сведения из теории СУБД, описан процесс разработки базы данных, приводятся макет и правила оформления пояснительной записки. УДК 004.65:378.147.091.313 (075.8) ББК 32.97 я7 ISBN 978-985-525-631-2 © Разорëнова Т.Р., 2012 © БНТУ, 2012 3 ВВЕДЕНИЕ Во всем мире организации накапливают или уже накопили в процессе сво- ей административно-хозяйственной деятельности большие объемы данных, в том числе и в электронном виде. Эти коллекции данных хранят в себе большие потенциальные возможности по извлечению новой аналитической информации, на основе которой можно и необходимо строить стратегию организации, выяв- лять тенденции развития рынка, находить новые решения, обусловливающие успешное развитие в условиях конкурентной борьбы. Для некоторых организа- ций такой анализ является неотъемлемой частью их повседневной деятельно- сти, другие только начинают активно приступать к нему. Для хранения, упорядочения и анализа больших объемов информации предназначены комплексы средств, именуемых информационными системами (ИС). Одними из видов таких, сегодня уже автоматизированных информацион- ных систем (АИС), являются базы данных (БД), управляемые с помощью си- стем управления базами данных (СУБД), и информационно-аналитические си- стемы, предназначенные как для хранения, так и для анализа хранимой инфор- мации, изучению которых и предназначен соответствующий раздел курса «Компьютерные информационные технологии». Основным назначением информационных систем является оперативное обеспечение пользователя информацией о внешнем мире путем реализации от- ношений типа «вопрос-ответ». Современные автоматизированные информационные системы: 1) ориентируются на конкретного пользователя, предоставляя ему удоб- ный интерфейс и необходимые для работы функции; 2) должны обеспечивать надежность и продолжительность хранения дан- ных, обладающих разными структурами; 3) должны обладать функциями, обеспечивающими ввод, обновление и удаление данных; 4) должны предоставлять данные для коллективной работы, обеспечивая согласованность их действий. Поэтому важным является понимание вопросов трудоемкости тех задач, которые стоят перед разработчиками АИС и теми, кто является их конечными пользователями или заказчиками. 4 1 ЦЕЛИ КУРСОВОГО ПРОЕКТИРОВАНИЯ Курсовая работа – важный этап обучения студента, где проявляются навы- ки ведения самостоятельной работы и овладения методикой проектирования и реализации задач по созданию автоматизированных информационных систем (АИС), основанных на базах данных (БД). При выполнении работы закрепля- ются теоретические знания, полученные при изучении курса. В ходе выполне- ния курсовой работы развивается индивидуальное творческое мышление сту- дента и проявляются его способности к самостоятельному выбору и примене- нию систем управления базами данных (СУБД) для решения задач в области баз данных. Целью выполнения курсовой работы является: – закрепление получаемых теоретических знаний; – привитие навыков по информационному поиску и использованию необ- ходимых материалов по исследуемой теме из научно-технической и справочной литературы; – развитие навыков практического применения теоретических знаний для решения конкретных задач на базе самостоятельно спроектированной базы данных; – привитие навыков самостоятельного изучения программного продукта и умения инсталляции необходимого программного обеспечения на персональ- ный компьютер; – освоение правил оформления курсовой работы в соответствии с требо- ваниями, установленными стандартом высшего учебного заведения (вуза). Темы курсовых работ определяются кафедрой, которая ведет дисциплины «Информационные таможенные технологии» и «Компьютерные информацион- ные технологии» и отражает один из разделов этих курсов – управление базами данных в деятельности таможенных органов и технологии организации, хране- ния и обработки данных. Курсовая работа состоит из двух частей: теоретическая и практическая. Теоретическая часть направлена на проведение обзора и изучение совре- менных технологий, применяемых при проектировании, разработке и эксплуа- тации автоматизированных информационных систем. Студент кратко описыва- ет изученные по литературным источникам компьютерные информационные технологии, применяемые при разработке современных информационных си- стем. Если имеется возможность применить изученные технологии в практиче- ской части курсовой работы, это должно быть отражено в задании. Практическая часть направлена на закрепление изученного материала и разработку небольшого приложения по управлению базой данных, построенной на основе спецификаций задания. Студент выполняет индивидуальное задание (или задания для группы студентов, но с индивидуальными спецификациями 5 для каждого студента) по созданию базы данных в заданной предметной обла- сти и разработке приложения по управлению этими данными. Приложение должно демонстрировать разработанные таблицы и запросы (представления), иметь дружественный интерфейс и позволять создавать отчетные документы для возможности проведения дальнейшего анализа данных. Наличие элементов автоматизации и применения клиент-серверных технологий позволит разрабо- тать реальный прототип информационной системы, который может стать осно- вой для дальнейшего его развития в дисциплинах специализации, курсовом и дипломном проектировании. Выбор среды разработки остается за студентом: или изучаемая в курсе, или может быть выбрана самостоятельно. При создании базы данных в систе- мах MS SQL Server необходима разработка хранимых процедур, курсоров, триггеров и демонстрация работы с ними, а также других возможностей по за- щите и управлению данными в клиент-серверных СУБД. Примерная тематика практической части курсовых работ: 1) разработка информационно-справочных систем и автоматизированных систем учета данных в определенной предметной области; 2) автоматизация рабочего места (АРМ). В соответствии с выбранной темой курсовой работы руководитель работы выдает студенту задание (Приложение В), в котором указывается тема, исход- ные данные для выполнения работы (спецификации), определяется содержание работы, сроки выполнения курсовой работы, а также согласовывается кален- дарный график выполнения отдельных этапов и всей работы. Консультации проводятся в соответствии с утвержденным на кафедре гра- фиком. 6 2 КРАТКИЕ ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ И ТЕРМИНОЛОГИЯ Необходимость изучения современных технологий работы с накопленной информацией обусловлена тем, что системы управления базами данных суще- ствуют уже много лет, многие из них обязаны своим происхождением системам с неструктурированными файлами на больших ЭВМ. Наряду с общепринятыми современными технологиями в области систем управления базами данных начинают появляться новые направления, что обусловлено требованиями рас- тущего бизнеса, все увеличивающимися объемами корпоративных данных и, конечно же, влиянием технологий Internet. Концепция баз данных (БД) как метод представления и накопления данных в электронном виде сформировалась к середине 60-х годов прошлого века в фирме IBM. В 1969 году была создана первая СУБД для управления и манипу- лирования данными как самостоятельными информационными объектами. В 1970 году была предложена реляционная модель данных для БД, и на ее основе начали создаваться популярные ныне реляционные СУБД. В рамках реляцион- ной модели с единых позиций были решены многие проблемы операционной (транзакционной) обработки данных. С середины 80-х годов прошлого столетия стали интенсивно накапливаться электронные информационные массивы данных организаций, корпораций, научно-исследовательских учреждений. Ведущие мировые корпорации создали огромные электронные массивы конструкторской документации и документа- ции по управлению производством. В это же время возникло четкое понимание, что сбор данных в электронном виде – не самоцель, а накопленные информаци- онные массивы могут быть полезны. Первыми осознали этот факт в области управления бизнесом и производством. В накопленных данных организации находится «информационный снимок» хронологии ее поведения на рынке. Ана- лиз истории административно-хозяйственной деятельности организации позво- лил существенно увеличить эффективность ее управления, эффективно органи- зовать взаимоотношения с клиентами, производство и сбыт. К ключевым факторам, определяющим развитие СУБД, относятся следу- ющие: − увеличение объемов данных и появление новых стандартов представле- ния и обмена данными; − появление новых типов данных (как структурированных, так и неструк- турированных) – XML, электронной почты, календарей, файлов, документов, географических данных и т. п. в дополнение к традиционным типам данных, поддерживаемым на уровне баз данных и файловой системы; − существенное снижение стоимости хранения самих данных, появление новых устройств хранения данных и уменьшение размеров накопителей. 7 В процессе своего развития приложения все больше и больше включают поддержку различных типов данных. Для обеспечения работоспособности та- ких приложений нужна соответствующая платформа, которая позволяла бы безопасно хранить такие данные, выполнять по ним поиск, анализировать их, синхронизировать и т. д. 2.1 Понятие предметной области Понятие предметной области базы данных является одним из базовых по- нятий информатики и не имеет точного определения. Предметная область определяет ту часть реального мира, которая будет моделироваться и реализо- вываться в системах оперативной обработки данных или справочно-аналити- ческих системах. Предметные области в базах данных формируются в соот- ветствии с направлениями деятельности организации и определяют наиболее общие вытекающие из ее семантики критерии и требования к системе. Чтобы определить список предметных областей для таких систем, необходимо опре- делить основные виды деятельности организации – например, продажи, произ- водство, клиенты и т. д. Проектирование базы данных представляет собой процесс отображения исследуемых явлений реального мира, называемых предметной областью, в виде данных в памяти компьютера. Основная цель проектирования базы дан- ных – это сокращение избыточности хранимых данных, а следовательно, эко- номия объема используемой памяти, уменьшение затрат на многократные опе- рации обновления и устранение возможности возникновения противоречий из- за хранения в разных местах сведений об одном и том же объекте. Перед созда- нием БД следует располагать описанием предметной области, а также иметь информацию для удовлетворения запросов пользователя и потребности в обра- ботке данных. На основе такого описания на этапе проектирования определяет- ся состав и структура данных предметной области. Анализ предметной области позволяет выделить ее сущности, определить первоначальные требования к функциональности и границы проекта. 2.2 Этапы проектирования базы данных Проектирование БД разбивают на два основных этапа: инфологическое (концептуальное) и даталогическое, которое, в свою очередь, подразделяется на логическое проектирование и физическое. На этапе инфологического проектирования имеет место восприятие реаль- ной действительности, абстрагирование, изучение и описание предметной обла- сти. Целью концептуального проектирования является разработка БД на основе описания предметной области. Это описание должно содержать совокупность документов и данных, необходимых для загрузки в БД, а также сведения об объ- ектах и процессах, характеризующих предметную область. Это может быть за- 8 фиксировано с помощью диаграмм потоков данных (Data Flow Diagrams – DFD- диаграмм). Разработка БД начинается с определения состава данных, подлежа- щих хранению в базе для обеспечения выполнения запросов пользователя. Далее производится их анализ и структурирование. На этапе логического проектирования производится организация выделен- ных данных в форму, принятую в выбранной СУБД. Целью логического проек- тирования является преобразование концептуальной модели в логическую. Для реляционной БД этот этап состоит в разработке структуры объектов, определе- нии связей между ними и выявлении ключевых реквизитов. Результат – постро- ение диаграмм «сущность–связь» (Entity Relationship – ER-диаграмм). Далее для построения оптимальной структуры базы данных проводится процесс нор- мализации. Этап физического проектирования дополняет логическую модель характе- ристиками, которые необходимы для определения способов физического хра- нения и использования БД, объема памяти и типа устройства для хранения. Ре- зультат – построение структуры таблиц с описанием типов данных и их декла- ративных ограничений. 2.3 Основные понятия ER-диаграмм Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity Relationship, диа- граммы «сущность–связь»). ER-диаграмма позволяет графически представить все элементы логической модели согласно простым, интуитивно понятным, но строго определенным правилам – нотациям. Термины, которыми оперирует реляционная модель данных, имеют соот- ветствующие «табличные» синонимы, представленные в таблице 1. Таблица 1 – Соответствие реляционных и табличных терминов Реляционный термин Соответствующий «табличный» термин База данных Набор таблиц Схема базы данных Набор заголовков таблиц Отношение Таблица Заголовок отношения Заголовок таблицы Тело отношения Тело таблицы Атрибут отношения Наименование столбца таблицы Кортеж отношения Строка таблицы Степень (арность) отношения Количество столбцов таблицы Мощность отношения Количество строк таблицы Домены и типы данных Типы данных в ячейках таблицы 9 Определение 1. Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность должна иметь наименование, выраженное существи- тельным в единственном числе. Примерами сущностей могут быть такие клас- сы объектов как Преподаватель, Студент, Отдел. Определение 2. Экземпляр сущности – это конкретный представитель данной сущности. Например, представителем сущности Преподаватель может быть Преподаватель Егоров. Экземпляры сущностей должны быть различимы, т. е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности. Определение 3. Атрибут сущности – это именованная характеристика, яв- ляющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характе- ризующими прилагательными). Примерами атрибутов сущности Преподава- тель могут быть такие атрибуты как Табельный номер, Фамилия, Имя, Отче- ство, Должность, Зарплата и т. п. Определение 4. Ключ сущности – это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экзем- пляра сущности. Неизбыточность заключается в том, что удаление любого ат- рибута из ключа нарушает его уникальность. Сущность может иметь несколько различных ключей. Определение 5. Связь – это некоторая ассоциация между двумя сущно- стями. Одна сущность может быть связана с другой сущностью или сама с со- бою. Связи позволяют по одной сущности находить другие сущности, связан- ные с нею. Например, связи между сущностями могут выражаться следующими фразами – «ПРЕПОДАВАТЕЛЬ может вести несколько ПРЕДМЕТОВ», «каж- дый СТУДЕНТ обязан числиться ровно в одной ГРУППЕ». Каждая связь может иметь один из следующих типов связи: «один-к- одному», «один-ко-многим» ими «многие-к-одному», «многие-ко-многим». Связи могут быть обязательными или необязательными. При выделении связей акцент делается на выявление их характеристик. При создании связи в одной из сущностей, называемой дочерней сущностью, создается новый атри- бут, называемый внешним ключом. Связь должна именоваться глаголом или глагольной фразой, где имя связи выражает некоторое ограничение или бизнес- правило и облегчает чтение диаграммы. 2.4 Способы документирования ER-модели База данных создается в несколько этапов, на каждом из которых необхо- димо согласовывать структуру данных с заказчиком и, что самое важное, под- вергать созданную структуру данных экспертизе внутри команды, которая со- здает систему. Поэтому представление данных должно быть простым и понят- 10 ным всем заинтересованным лицам. Именно по этой причине, наибольшее рас- пространение получило представление базы данных под названием «сущность– связь» (Entity Relationship), которое также известно как ER-диаграмма. Метод моделирования «сущность–связь» был предложен С. Ченом в 1976 году. В диаграммах Чена информационные объекты (сущности) изображаются прямоугольниками, связи – ромбами или шестиугольниками, атрибуты – ова- лами. Сущности соединяются линиями, над которыми могут проставляться степени связи (1 или буква М) и необходимые пояснения. Для представления элементов модели были разработаны несколько других графических нотаций: нотация Мартина, нотация IDEF1X, нотация Баркера и др. Проектировщик может выбрать графическую нотацию по своему вкусу. Построение ER-диаграмм, как правило, ведется с использованием CASE- средств, например в MS Office Visio 2007 или в ERwin. В таблице 2 приведены обозначения для двух способов документирования ER-модели. Таблица 2 – Способы документирования ER-модели Определение Обозначение в нотации Баркера Обозначение в нотации Чена Сущность Каждая сущность в модели изобража- ется в виде прямоугольника с наиме- нованием: Каждая сущность в модели изобража- ется в виде прямоугольника с наиме- нованием: Атрибут Атрибуты изображаются в пределах прямоугольника, определяющего сущность: Атрибут – овал с названием атрибута: Ключевые атрибуты Ключевые атрибуты изображаются на диаграмме подчеркиванием: Ключевой атрибут – овал с подчеркну- тым названием ключевого атрибута: 11 Продолжение таблицы 2 Определение Обозначение в нотации Баркера Обозначение в нотации Чена Связи Графически связь изображается ли- нией, соединяющей две сущности: Связь – ромб с названием связи- отношения: Типы связей Виды связей Примеры См. рисунок 1 и рисунок 2 См. рисунок 3 Как правило, ER-диаграммы используются для презентаций и обсуждения структуры данных с экспертами предметной области. Ниже приведены приме- ры разработки простой концептуальной ER-модели в различных нотациях. Рисунок 1 – Пример связи «многие-ко-многим» Связь «многие-ко-многим» может быть создана только на уровне логиче- ской модели. Ее необходимо преобразовать к связи «один-ко-многим», изменив глагольную форму в существительное для связующей сущности, которая может иметь дополнительные атрибуты и иметь ключ. Рисунок 2 – Пример преобразования связи M:N к виду «один-ко-многим» 12 Рисунок 3 – Пример диаграммы Чена Независимо от выбранной нотации, действия проектировщика базы дан- ных при ER-моделировании сводятся к следующему алгоритму. Для каждой сущности предметной области базы данных необходимо: − получить список атрибутов сущности; − определить функциональные зависимости; − определить уникальный идентификатор сущности; − выполнить нормализацию сущности; − назначить первичные ключи новых, полученных в результате нормали- зации сущностей; − сформировать бизнес-правила поддержки целостности сущности. Для каждой связи между сущностями необходимо: − определить степень связи; − определить обязательность вхождения сущности в связь; − разрешить связи «многие-ко-многим»; − сформировать бизнес-правила поддержки целостности связей; − документировать логическую модель реляционной базы данных; − проверить логическую модель реляционной базы данных. 2.5 Нормализация модели «сущность–связь» Нормализация – процесс проверки и реорганизации сущностей и атрибу- тов с целью удовлетворения требований к реляционной модели данных: каждый атрибут должен быть определен для своей сущности. Это достигается путем раз- биения таблиц на две или более, обладающих лучшими свойствами при включе- нии, изменении и удалении данных, и делается не столько с целью экономии па- мяти, сколько для исключения возможной противоречивости хранимых данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т. е. исключена избыточность информации. Процесс нормализации сводится к последовательно- му приведению структуры данных к нормальным формам – формализованным требованиям к организации данных. Известно 6 нормальных форм: 13 − первая нормальная форма (1NF); − вторая нормальная форма (2NF); − третья нормальная форма (3NF); − нормальная форма Бойса–Кодда (усиленная 3NF); − четвертая нормальная форма (4NF); − пятая нормальная форма (5NF). На практике обычно ограничиваются приведением данных к третьей нор- мальной форме. Отношения в 3NF являются самыми «хорошими» с точки зре- ния того, что устранены аномалии обновления, удаления и вставки и требуются только стандартные триггеры для поддержания ссылочной целостности. Для углубленного изучения нормализации можно рекомендовать книгу К. Дж. Дей- та «Введение в системы баз данных» [1]. Нормальные формы основаны на понятии функциональной зависимости. Первая нормальная форма (1NF). Сущность находится в первой нор- мальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения. Для приведения сущности к первой нормальной форме следует: − разделить сложные атрибуты на атомарные; − создать новую сущность; − перенести в нее все «повторяющиеся» атрибуты; − выбрать возможный ключ для нового первичного ключа или создать его; − установить идентифицирующую связь от прежней сущности к новой, пер- вичный ключ прежней сущности станет внешним ключом для новой сущности. Вторая нормальная форма (2NF). Сущность находится во второй нор- мальной форме, если она находится в первой нормальной форме и каждый неключевой атрибут полностью зависит от первичного ключа (не должно быть зависимости от части ключа). Вторая нормальная форма имеет смысл только для сущностей, имеющих сложный первичный ключ. Для приведения сущности ко второй нормальной форме следует: − выделить атрибуты, которые зависят только от части первичного ключа, создать новую сущность; − поместить атрибуты, зависящие от части ключа, в их собственную (но- вую) сущность; − установить идентифицирующую связь от прежней сущности к новой. Третья нормальная форма (3NF). Сущность находится в третьей нор- мальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть транзитивной зависимости между неключевыми атрибутами). Для приведения сущности к третьей нормальной форме следует: − создать новую сущность и перенести в нее атрибуты с одной и той же за- висимостью от неключевого атрибута; 14 − использовать атрибут (атрибуты), определяющий (определяющие) эту зависимость, в качестве первичного ключа новой сущности; − установить неидентифицирующую связь от новой сущности к старой. Таким образом, переход от ненормализованных отношений к отношениям в 3NF может быть выполнен при помощи алгоритма нормализации. Алгоритм нормализации заключается в последовательной декомпозиции отношений для устранения функциональных зависимостей атрибутов от части сложного ключа (приведение к 2NF) и устранения функциональных (транзитивных) зависимо- стей неключевых атрибутов друг от друга (приведение к 3NF). 2.6 Основные объекты реляционных БД К числу основных объектов реляционных БД относятся таблица, представ- ление и пользователь. Таблица (Table) является базовой структурой реляционной БД. Она пред- ставляет собой единицу хранения данных – отношение. Таблица представляет со- бой двумерный массив данных, в котором колонка определяет значение, а строки содержат данные. Таблица идентифицируется в БД своим уникальным именем. Представление (View) – это поименованная, динамически поддерживае- мая СУБД выборка из одной или нескольких таблиц базы данных. В MS Access это запрос. Оператор выборки ограничивает видимые пользователю данные. Обычно СУБД гарантирует актуальность представления: его формирование производится каждый раз, когда представление используется. Иногда представ- ления или запросы называют виртуальными таблицами. Пользователь (User) – это объект, обладающий возможностью создавать или использовать другие объекты базы данных и запрашивать выполнение функций СУБД, таких, как организация сеанса работы, изменение состояния базы данных и т. д. При использовании клиент-серверных баз данных MS SQL Server имеется ряд дополнительных объектов, таких, как определенные пользователем типы данных и правила. Определенные пользователем типы данных (User-defined data types) представляют собой определенные пользователем типы атрибутов (домены), которые отличаются от поддерживаемых СУБД типов. Они определяются на основе встроенных типов. Правила (Rules) – это декларативные выражения, ограничивающие воз- можные значения данных. Для формулировки правила используются допусти- мые предикатные выражения SQL. Для обеспечения эффективного доступа к данным в реляционных СУБД поддерживается ряд других объектов, в частности индекс. 15 Индекс (Index) – это объект базы данных, создаваемый для повышения производительности выборки данных и контроля уникальности первичного ключа (если он задан для таблицы). Для обработки данных специальным образом или для реализации поддержки ссылочной целостности базы данных в MS SQL Server используются объекты: хранимая процедура, функция, триггер. С помощью этих объектов базы данных можно выполнять так называемую построчную обработку данных, для чего ис- пользуются курсоры. С точки зрения приложений баз данных построчная обра- ботка – это последовательная выборка данных по одной строке, ее обработка и пе- реход к обработке следующей строки. Данные объекты реляционной базы данных представляют собой програм- мы, т. е. исполняемый код. Этот код обычно называют серверным кодом, по- скольку он выполняется компьютером, на котором установлено ядро реляцион- ной СУБД. Планирование и разработка такого кода является одной из задач проектировщика реляционной базы данных. Хранимая процедура (Stored procedure) – это объект базы данных, пред- ставляющий поименованный набор команд SQL и/или операторов специализи- рованных языков обработки программирования базы данных. Функция (Function) – это объект базы данных, представляющий поимено- ванный набор команд SQL и/или операторов специализированных языков обра- ботки программирования базы данных, который при выполнении возвращает значение – результат вычислений. Триггер (Trigger) – это объект базы данных, который представляет собой специальную хранимую процедуру. Эта процедура запускается автоматически, когда происходит связанное с триггером событие (например, вставка, измене- ние или удаление строки в таблице). Курсор (Cursor) – это механизм, предоставляющий пользователю возмож- ность доступа к любой строке выборки по ее номеру. Курсор представляет свое- го рода окно, накладываемое на результат выборки. Пользователь может рабо- тать в каждый момент времени только с одной строкой, но, перемещая окно, он способен получить доступ к любой строке выборки. Для эффективного управления разграничением доступа к данным поддер- живается объект роль. Роль (Role) – объект базы данных, представляющий собой поименованную совокупность привилегий, которые могут назначаться пользователям, категори- ям пользователей или другим ролям. 2.7 Структура таблиц и целостность данных Когда приступают к проектированию таблиц базы данных, требуется принять некоторые решения, относящиеся к их структуре. К этим решениям относится определение того, какие элементы данных должны храниться в этих 16 таблицах и как таблицы будут связаны друг с другом. Эта работа поможет представить общую картину базы данных, прежде чем вы углубитесь в создание таблиц. Ниже дан перечень вопросов для принятия решений: − Какие данные будут храниться в каждой из таблиц? − Какие колонки будут созданы для хранения данных и какие у них будут имена? − Какие будут требования к диапазону данных, хранящихся в колонках (какие данные разрешено в них хранить), и какие типы данных должны приме- няться для каждой из колонок? − Будут ли иметься колонки, которые могут содержать null-значения, или же вместо этого могут применяться значения по умолчанию? − Какие колонки станут первичными ключами, а какие – внешними ключами? − Какие типы ограничений должны использоваться? − Для какой колонки или колонок должны быть определены индексы? − Какие пользователи должны иметь доступ к тем или иным таблицам? Необходимо найти ответы на как можно большее количество этих вопросов о проектировании системы и записать их на листок бумаги или в компьютерной программе для рисования схем, чтобы осознать общую конструкцию таблиц вашей базы данных, прежде чем начать создавать их. Нужно определить, каким образом пользователи будут осуществлять доступ к данным. Например, можно определить, что некоторая таблица будет предназначена только для чтения или же в нее будут производиться вставки, удаления или обновления данных. Необ- ходимо предусмотреть, какие запросы будут выполняться чаще всего и из каких колонок будут извлекаться данные. Надо определить, какая информация действительно необходима для базы данных, а какую хранить не надо: она будет получена в результате вычислений. При задании типа данных у колонки задаются следующие атрибуты: − тип данных, которые могут содержаться в колонке (например, символь- ные данные, целые числа или изображения); − размер (длина) данных, хранимых в колонке; − точность чисел (этот атрибут применяется только для числовых типов данных), т.е. количество цифр, содержащихся в числах; − масштаб чисел (этот атрибут применяется только для числовых типов дан- ных), т. е. количество цифр, способных помещаться справа от десятичной точки; − null-значение (null value) – это неизвестное значение, для которого при- меняется обозначение NULL. Колонки, способные хранить null-значения, могут оказаться полезными в случаях, когда необходимая информация пока что недо- ступна для вас. Как правило, не следует применять null-значения. Из-за них за- просы и обновления становятся более сложными, кроме того, к колонкам, спо- собным хранить null-значения, нельзя применять некоторые настройки, такие, как первичные ключи и свойство IDENTITY. Вместо применения null-значений в колонке можно задавать значения по умолчанию (default value). 17 Декларативные ограничения. Ограничения автоматически обеспечивают целостность данных. Ограничения задают правила, которые определяют значения данных, допустимые для какой-либо колонки. Они позволяют ограничивать значения данных, которые вводятся в колонку, чтобы в этой колонке не оказались неверные значения. Например, с помощью ограничения можно ограничить значения колонки для экзаменационной оценки диапазоном значений целого типа от 1 до 10, а для выбора пола – принадлежностью набору символьных значений М или Ж. В результате любые значения вне этого диапазона нельзя будет ввести в данную колонку. Ограничение NOT NULL задается в описании колонки, чтобы воспрепятствовать вставке null-значений в эту колонку (в противоположность ограничению NULL, которое разрешает присваивать null-значения). Ограничение UNIQUE устанавливает, что в колонке или наборе колонок не будут допускаться дублированные значения; иными словами, обеспечивается уникальность значений в этой колонке или наборе колонок. Ограничение PRIMARY KEY используется, чтобы задать первичный ключ таблицы, представляемый колонкой или набором колонок, уникальным образом идентифицирующих строку таблицы. Поскольку первичный ключ идентифи- цирует строку, соответствующая колонка никогда не содержит значения NULL. В этом состоит отличие ограничения PRIMARY KEY от ограничения UNIQUE, которое допускает null-значения. Таблица может иметь только одно ограничение PRIMARY KEY. Ограничение FOREIGN KEY определяет внешний ключ, который задает связь между двумя таблицами. Колонка или колонки внешнего ключа одной таблицы ссылаются на потенциальный ключ (одна или несколько колонок) в другой таблице. При вставке строки в таблицу с ограничением FOREIGN KEY значения, которые должны быть внесены в колонку или колонки, определенные как внешний ключ, сравниваются со значениями в потенциальном ключе ссылочной таблицы. Декларативная поддержка ограничений целостности заключается в опре- делении ограничений средствами языка определения данных (DDL – Data Definition Language). Например, следующий оператор создает таблицу Куратор и определяет для нее некоторые ограничения целостности: CREATE TABLE Куратор (Группа_Id INTEGER, ФИО CHAR(30) NOT NULL, FOREIGN KEY (Группа_Id) REFERENCES Группа(Группа_Id) ON UPDATE CASCADE ON DELETE CASCADE); 18 Ссылочная целостность. При работе БД должна обеспечиваться целост- ность данных. Под целостностью данных понимают обеспечения целостности связей между записями в таблицах при удалении записей из первичных таблиц. То есть при удалении записей из первичных таблиц, автоматически должны удаляться связанные с ними записи из вторичных таблиц. В случае несоблюдения целостности данных со временем в БД накопится большое количество записей во вторичных таблицах, связанных с несущест- вующими записями в первичных таблицах, что приведет к сбоям в работе БД и ее засорению неиспользуемыми данными. Для обеспечения целостности данных используют диаграммы и триггеры. Диаграммы – это компоненты БД, которые блокируют удаление записей из первичных таблиц, если существуют связанные с ними записи во вторичных таблицах. Следовательно, диаграммы предотвращают нарушение целостности данных. Для поддержания ссылочной целостности используется каскади- рование: разрешить выполнение требуемой операции, но внести каскадные из- менения в другие отношения так, чтобы не допустить нарушения ссылочной целостности. Триггеры – это аналог процедур обработчиков событий в Visual Basic. То есть они выполняют команды SQL, если происходят какие-либо действия с таблицей (например, добавление, изменение или удаление записей). При помощи триггеров можно организовать автоматическое удаление записей из вторичной таблицы при удалении связанной с ними записи из первичной таблицы. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер свя- зан. Очень важным является то, что пользователь не может обойти триггер. Триггер срабатывает независимо от того, кто из пользователей и каким спосо- бом инициировал событие, вызвавшее запуск триггера. Таким образом, основ- ное назначение триггеров – автоматическая (процедурная) поддержка целост- ности базы данных. Структуры таблиц определяют физическую модель данных: отношения, разработанные на стадии формирования логической модели данных, преобра- зуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атри- бутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД. Средствами документирования разработки физической модели будем счи- тать описания таблиц и их атрибутов. В таблице 3 приведено описание двух связанных отношений (объектов БД), представленных во фрагменте ER- диаграммы на рисунке 4, определены таблицы и названия полей, заданы огра- ничения. В колонке «Признак ключа» определяется декларативное определение первичного ключа и внешнего ключа – поля связи. 19 Рисунок 4 – Фрагмент ER-диаграммы Таблица 3 – Описание таблиц и их атрибутов Информационный объект (таблица) Название реквизита Обозначение реквизита Признак ключа Тип данных (размер) Ограничения ГЭК № ГЭК ГЭК Уникальный ключ Счетчик Уникальное № приказа Приказ Текст Заседание_ГЭК Код заседа- ния Код Уникальный ключ Счетчик Уникальное № ГЭК ГЭК Поле связи Числовой (подстановка поля ГЭК из таблицы ГЭК) Обязательное поле, по умол- чанию – 1 Дата и время заседания Дата Date Формат «дата и время» Тип ГЭК Вид Текст (под- становка из значений «ГОС» или «ГЭК») 3 символа, обязательное поле Место засе- дания Место Текст 30 символов В соответствии с приведенным выше описанием необходимо представить каждую таблицу проектируемой базы данных. Если база данных реализуется в MS Access, а затем преобразовывается в MS SQL Server, возможно определение процедурной поддержки целостности базы данных, т. е. разрабатываются триггеры. 20 3 ПОДХОДЫ К ПРОЕКТИРОВАНИЮ БАЗ ДАННЫХ 1 способ: Проектирование на основе бумажных документов. Основой проектирования являются бланки и другие виды документации, с которыми работают конечные пользователи. По формальным правилам [11] из документов надо выделить информационные объекты (ИО), количество кото- рых зависит от класса документов, представленных в таблице 4. Таблица 4 – Описание классов документов Класс Описание 1. Список Формируется один ИО из изменяемых реквизитов содержа- тельной части документа. 2. Папка из списков Формируется два ИО: 1) из изменяемых реквизитов заголовка папки; 2) из изменяемых реквизитов содержательной части документа. 3. Архив из папок Формируется три ИО: 1) из изменяемых реквизитов заголовка папки; 2) из изменяемых реквизитов заголовочной части документа; 3) из изменяемых реквизитов содержательной части документа. Вначале необходимо сравнить несколько отдельных экземпляров докумен- та (и их папок, если они имеются) и проанализировать, какие атрибуты могут изменяться. Сразу следует исключить из дальнейшего рассмотрения постоян- ные и вычисляемые реквизиты. Затем для выделения ИО из документов необ- ходимо разделить их реквизиты на группы в соответствии с ИО, которые они описывают. Например, при разработке базы данных для учета преподавателей вуза за основу можно взять представленный на рисунке 5 документ с бланком информа- ции о составе кафедры, откуда выбираются и группируются реквизиты, образу- ющие два объекта предметной области – Кафедра и Преподаватель, поскольку в бланке можно выделить изменяемые части: заголовочную (информация о кафед- ре) и содержательную (список и информация о преподавателях кафедры). 21 Рисунок 5 – Пример бланка, на основе которого проектируется база данных Определяя предметную область, предполагается, что база данных проекти- руется для штатного состава, т. е. преподаватели работают на одной из кафедр вуза. Тогда инфологическая модель выглядит так, как представлено на рисунке 6 (на одной кафедре может работать один или много преподавателей или не рабо- тать ни одного, но каждый преподаватель может работать только на одной из кафедр – совместительство не предусмотрено). Кафедра Преподаватель Рисунок 6 – ER-диаграмма проектируемой базы данных Выписываем все реквизиты, даем им имена и определяем функциональные зависимости (таблица 5): Таблица 5 – Имена и функциональные зависимости реквизитов Документ Наименование реквизита Имя реквизита Функциональная зависимость С пи со к пр еп од ав ат ел ей ка ф ед ры Код кафедры ККАФ Название кафедры НКАФ Телефон ТЕЛ Фото зав.кафедрой ФОТО Таб.номер ТАБН Фамилия, имя, отчество ФИО Должность ДОЛЖН Ученая степень СТ Код кафедры ККАФ М 1 Это поле вводится для связи объектов Эти поля вводятся для идентификации объектов 22 Полученная информационно-логическая модель (ИЛМ) представлена на рисунке 7. КАФЕ ДРА ПРЕПОДАВА ТЕЛЬ ККАФ ТАБН НКАФ ККАФ ТЕЛ ФИО ФОТО ДОЛЖН СТ Рисунок 7 – ИЛМ базы данных «Кафедра» 2 способ: Проектирование на основе имеющейся структуры или внеш- них данных. Иногда проектирование базы данных начинается с предлагаемых объектов будущей базы данных. Тогда необходимо определить границы предметной об- ласти, цели проектирования, самостоятельно продумать, какими атрибутами будут описываться объекты, выявить их взаимосвязи на основе взаимодействия экземпляров этих объектов. Для этого можно разработать бланк учетной ин- формации и далее действовать по описанию 1-го способа. Например, требуется разработать базу данных «Успеваемость» с таблица- ми Студент, Предмет, Экзамен. Исходя из названия, представляем предметную область следующим образом: в вузе необходимо вести учет сдачи экзаменов в сессию. Исходные данные могут быть выбраны из ведомости, которая выдается на экзамен. В ней фиксируют название предмета, фамилию преподавателя, се- местр, группу и список студентов группы. Фраза «Cтудент сдает Экзамен по Предмету» позволяет выявить множественную зависимость между сущностями Студент и Предмет, которые свяжет связующая сущность Экзамен с описатель- ным атрибутом – оценкой. На рисунке 8 представлена информационно- логическая модель (ИЛМ), которая требует дальнейшей нормализации, по- скольку заметно излишнее дублирование данных в таблицах. СТУДЕНТ ЭКЗАМЕН ПРЕДМЕТ КодСтуд КодЭкзамена КодПредмета Имя КодСтуд Название Фамилия КодПредме- та Семестр Группа Дата Препод Оценка 1 1 М М 1 М 23 Рисунок 8 – ИЛМ базы данных «Успеваемость» Если в основе разработки имеются данные, расположенные в других источ- никах, например, в электронных таблицах, то необходимо провести анализ наименований полей списка электронной таблицы, выявить объекты, построить их взаимосвязи, определиться с целями разработки базы данных. Ниже на ри- сунке 9 представлена электронная таблица с данными об оплате коммунальных услуг. Из списка полей можно выявить следующие объекты и их атрибуты: Услу- га (Наименование, Тариф), Плательщик (Фамилия, Адрес) и Оплата (Код, Дата, Количество: метраж – для квартплаты, объем – за газ и электроэнергию, мину- ты – за телефон и т. д.). Вычисляемое поле Всего в базу данных не заносится. Рисунок 9 – Excel-таблица с данными «Коммунальные услуги» Для проектирования базы данных информационно-логическая модель (ИЛМ) может выглядеть так, как показано на рисунке 10. 24 УСЛУГА ОПЛАТА ПЛАТЕЛЬЩИК КодУслуги Код КодЛица Наименование КодУслуги Фамилия Тариф КодЛица Адрес Дата КолЖильцов Количество Метраж Рисунок 10 – ИЛМ базы данных «Коммунальные услуги» Таблицы MS Access могут строиться на основе импорта данных, в частно- сти из электронных таблиц. Используя эту возможность, вся таблица перено- сится в базу данных, затем, используя язык SQL, делаются проекции данных в новые таблицы, структура которых продумывается заранее. Затем эти таблицы в Конструкторе описываются ключевыми реквизитами и полями связи. Уточ- няются (корректируются) типы данных. Важно не потерять исходную инфор- мацию, которая была в электронной таблице. При корректной работе в базе данных получатся таблицы-справочники и таблицы с учетной информацией, что разрешает аномалии, присущие ненорма- лизованным отношениям импортированной исходной таблицы. 3 способ: Проектирование на основе описания предметной области – общей постановки. Например, требуется разработать базу данных для ведения учета денежных затрат на покупки членами семьи. Процесс проектирования состоит в следующем: 1. Требуется определить, чем конкретно должна будет заниматься база данных. Для нашего примера это решение следующих задач: − учет покупок; − учет ежедневных денежных затрат на покупки; − учет расходов каждого члена семьи и т. д. Эти требования и пожелания к разрабатываемой БД записываются в стол- бик на большом листе бумаги. 2. Следует просмотреть все требования, удалить все повторяющиеся или явно взаимоисключающие условия и свести все в одну таблицу (таблица 6). 1 1 М М 25 Таблица 6 – Выделение реквизитов Требования Описание и способ использования информации Реквизиты Принадлежность к объекту Учет покупок Ввод и вычисление – что куплено, в каком количестве, на какую сумму Продукт, Цена, Количество, Сумма денег ПРОДУКТ, ПОКУПКА Расходы членов семьи Ввод и вычисление – кто и когда совершил покупку, сколько де- нег потратил ЧленСемьи, Дата, Сумма денег. ПЕРСОНА, ПОКУПКА Учет денеж- ных затрат Вычисление – когда и какая сумма денег потрачены. Дата, Сумма денег ПОКУПКА 3. Необходимо конкретизировать требования к каждому объекту и выявить связи между ними, что показано на рисунке 11. Анализируя исходные данные, можно выявить связи между объектами Персона и Продукт как «многие-ко-многим», что требуется разбить при помо- щи дополнительной сущности (глагола), который следует превратить в имя су- ществительное. ПЕРСОНА ПОКУПКА ПРОДУКТ КодИмя КодПокупки КодПродукта Имя КодИмя Название КодПродукта Цена Дата Количество Рисунок 11 – ER-модель и ИЛМ базы данных «Затраты на покупки» 4. Далее проектируются таблицы, определяются данные, хранящиеся в них, прикидывается домен для данных, описывается каждое данное. 5. Затем следует провести нормализацию таблиц, в результате чего долж- ны быть получены следующие итоги: все пожелания воплощены в конкретные типы и виды данных, все данные взаимосвязаны между собой. Эти связи позволят составить схему функционирования всей БД. В проек- тируемой базе данных можно делать выборки по временным интервалам (сум- Продукт Персона Покупает 1 1 М М 1 1 М М 26 мы за покупки за день, неделю, месяц и т. д.), оценить на что уходит семей- ный бюджет. 4 ВЫПОЛНЕНИЕ ПРАКТИЧЕСКОГО РАЗДЕЛА КУРСОВОЙ РАБОТЫ В процессе создания базы данных в MS Access (рисунок 12) вначале осу- ществляется конструирование таблиц, создаются схемы данных, которые осу- ществляют связи между таблицами. Внешний вид схемы совпадает с графиче- ским представлением информационно-логической модели. В схеме данных мо- гут быть заданы параметры обеспечения целостности БД, если модель разработана в соответствии с требованиями нормализации. Рисунок 12 – Процесс проектирования структуры базы данных в MS Access Для создания оптимальной структуры разрабатываемой базы данных и про- ектирования интерфейса по работе с ней следует применить следующие шаги: 1. Исследуйте моделируемую информационную среду: 1.1. Определите, откуда и в каком виде поступает информация. 1.2. Как часто информация меняется, кто и как работает с данными. 1.3. Какие бумажные носители, формы или файлы используются при обработке информации. 2. Создайте список объектов с их свойствами и атрибутами: 2.1. Сначала создайте список всех возможных атрибутов, а затем сгруп- пируйте их в объекты. 2.2. Проанализируйте объекты на соответствия их атрибутов (возможно, появятся дополнительные объекты или другие атрибуты). 27 2.3. Проведите процедуру нормализации: приведите разрабатываемую базу данных к 3-й нормальной форме. 2.4. Задокументируйте свои конструктивные решения в виде диаграммы «сущность–связь» (ER-диаграмма) или информационно-логической модели (ИЛМ). 2.5. Создайте макет таблиц и связей между ними. 3. Обоснуйте выбор СУБД и среды разработки клиентского приложения: 3.1. Разработайте физическую модель данных (объекты, поля и их типы, ограничения и значения по умолчанию, null-значения и прочие правила, обес- печивающие декларативную целостность данных). 3.2. Предусмотрите обеспечение целостности данных по ссылкам на уровне каскадных связей таблиц или в виде триггеров и обоснуйте свои ре- шения. 3.3. Разработайте интерфейс клиентского приложения. 4. Создайте базу данных, поместите в нее прототипы данных: 4.1. Разработайте ряд запросов, задокументируйте их в виде SQL- скриптов и опишите полученные результаты. 5. Разработайте оконный интерфейс для демонстрации работы с базой данных: 5.1. Обеспечьте эффективность функционирования, простоту и удобство эксплуатации. 5.2. Разработайте управляющую кнопочную форму. 6. Разработайте отчетные документы для демонстрации работы с базой данных: 6.1. Обеспечьте эффективность представления информации, простоту и удобство просмотра. 6.2. Разработайте отчеты с группировками данных. 7. Проведите тестирование и опишите руководство пользователя по работе с базой данных. Если база данных преобразована в среду MS SQL Server, разработайте хранимые процедуры, триггеры, курсоры, которые необходимы для обработки и извлечения данных, предусмотрите и обоснуйте способы обеспечения без- опасности работы с базой данных на уровне групп пользователей. 28 5 ОФОРМЛЕНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ Пояснительная записка должна отражать ход выполнения курсовой работы и содержать все структурные элементы отчетного документа. Содержательная часть состоит из двух разделов, названия которых должны соответствовать теме курсовой работы и разрабатываемой базе данных. Мини- мальная реализация системы управления базами данных подразумевает созда- ние базы данных и запросов, осуществляющих выполнение тех функций, кото- рые оговорены в задании. В том случае, если СУБД реализуется не полностью, например, отсутствуют некоторые ограничения целостности или функциональ- ные возможности, а также отчеты и формы, это должно быть указано в поясни- тельной записке. Макет отчетного документа (расчетно-пояснительная записка) по курсовой работе представлен на рисунке 13 и должен иметь следующую структуру. Рисунок 13 – Структура расчетно-пояснительной записки 29 Титульный лист является первой страницей работы и служит источником информации, подтверждающей допуск работы к защите. Образец титульного листа приведен в Приложении А*. Лист пояснительной записки является второй страницей работы и слу- жит источником информации, необходимой для обработки и поиска документа. Образец листа пояснительной записки приведен в Приложении Б*. Задание на курсовую работу выдается студенту руководителем работы. Содержание работы отражается в спецификациях к исходным данным задания, является индивидуальным. Образец листа задания на курсовое проектирование приведен в Приложении В*. Содержание следует собирать по основным заголовкам курсовой работы: введению, номерам и заголовкам разделов, подразделов, заключению, списку использованных источников и приложений с указанием номера страницы, на которой помещен каждый заголовок. Сборку содержания следует выполнять средствами текстового редактора на основе применения заголовочных стилей 1-го и 2-го уровней или с помощью полей, управляющих сборкой оглавления. Введение характеризует современное состояние проблемы, которой по- священа работа, должно содержать цель курсовой работы и задачи, на решение которых направлено данное исследование. Во введении дается обоснование ак- туальности темы с теоретической и практической точки зрения. Во введении следует четко формулировать, в чем конкретно заключается смысл описывае- мой работы, называется предметная область, на базе которой выполняется практическая часть работы. Основная часть является наиболее важной и результативной частью рабо- ты. По структуре она зависит от темы курсовой работы и составляющих ее ча- стей (теоретической и практической). Материал основной части отражает сущ- ность, методику и основные результаты выполненной работы. Здесь же излага- ются вопросы по применению программного обеспечения на этапах решения задач по теме практической разработки. Таким образом, основная часть** должна содержать следующие разделы и их наполнение: 1 Указать название теоретического раздела работы (подразумевает раскрытие тематики теоретической части курсовой работы с возможной увязкой ее с практической разработкой): 1.1 Обзор и анализ источников 1.2 Проектные решения * Шаблон электронного документа доступен в сети факультета и на сайте кафедры «Таможенное дело». ** В зависимости от особенностей выполненной работы основную часть можно представить в виде текста, со- держащего иллюстрации, схемы и таблицы. 30 2 Проектирование БД «указать название» (анализ предметной области, инфоло- гическое и физическое проектирование разрабатываемой базы данных): 2.1 Анализ предметной области и составление спецификаций к данным 2.2 Построение концептуальной и логической модели данных 2.3 Физическая модель данных (описание таблиц с атрибутами и их свой- ствами, хранимых процедур, пользовательских функций, курсоров и триггеров) 3 Разработка приложения по работе с базой данных (обоснование выбора СУБД, проектирование запросов, форм, отчетов, управляющей формы прило- жения, элементов автоматизации): 3.1 Назначение объектов 3.2 Структура приложения 3.3 Руководство пользователя Заключение является одной из важнейших частей курсовой работы, кото- рое содержит оценку в виде выводов основных, наиболее важных полученных результатов. Заключение должно содержать: основные выводы по результатам выполнения работы или отдельных её этапов; оценку полноты решений постав- ленных задач; рекомендации и исходные данные по конкретному использова- нию результатов работы; оценку научно-технического уровня выполненной ра- боты. В процессе работы могут выявиться новые (в известном смысле неожи- данные) закономерности, новые данные. Все эти сведения также должны быть оценены в заключении. Помимо оценки результатов работы, заключение может содержать информацию о путях и целях дальнейшей работы или мотивирован- ный вывод о нецелесообразности продолжения работы. Список использованных источников должен содержать сведения об ис- точниках, использованных при выполнении работы, в соответствии с требовани- ями ГОСТ 7.1. Источники следует располагать в порядке появления ссылок в тексте записки. В таблице 7 приведены примеры оформления описания изданий. Приложения оформляют как продолжение работы в виде отдельной части, располагая их в порядке появления ссылок в тексте. Приложения должны иметь названия. В приложениях можно размещать таблицы с альбомной ориентацией. В приложения могут быть включены SQL-скрипты для создания базы дан- ных и ее таблиц, разработанных SQL-запросов (представлений), функций, хра- нимых процедур, курсоров, триггеров, основные фрагменты текстов программ клиентской части приложения и другая дополнительная информация (на усмот- рение студента). Таблица 7 – Примеры библиографического описания изданий 31 Характеристика источника Пример оформления Один, два или три автора Сенов, А.С. Access 2007 / А.С. Сенов. – СПб и др.: Питер, 2008. – 266 с. Астахова, И.Ф. SQL в примерах и задачах: учеб. пособие / И.Ф. Астахова, А.П. Толстобров, В.М. Мельников. – Минск: Новое знание, 2002. – 176 с. Более трех авто- ров Культурология: учеб. пособие для вузов / С.В. Лапина [и др.]; под общ. ред. С.В. Лапиной. – 2-е изд. – Минск: Системс, 2004. – 470 с. Учебник, учеб- ное пособие, словарь, спра- вочник Эксплуатация и техническое обслуживание дорожных машин, автомобилей и тракторов: учеб. / С.Ф. Головин, В.М. Коншин, А.В. Рубайлов и др.; под ред. Е.С. Локшина. – М.: Ма- стерство, 2002. – 462 с.: ил. Разоренова, Т.Р. Управление базами данных: учебно-методич. пособие для студентов специ- альностей: 1–96 01 01 «Таможенное дело», 1–26 02 02 «Менеджмент», 1–25 01 08 «Бухгалтер- ский учет, анализ и аудит», 1–25 01 07 «Экономика и управление на предприятии», «Финансо- вое обеспечение и экономика боевой и хозяйственной деятельности войск (сил)» / Т.Р. Разоре- нова, О.В. Альшевская. – 2-е изд., испр. и доп. – Минск: Изд-во БНТУ, 2011. – 120 с. Иллюстрированный словарь по искусству и архитектуре / сост. Р.П. Андреева. – СПб.: Из- дат. Дом «Литера», 2003. – 447 с.: ил. Методические указания Методические указания к выполнению курсовой работы по дисциплине «Технология и оборудование восстановления деталей машин и приборов» для студентов специальности 1–36 01 04 «Оборудование и технологии высокоэффективных процессов обработки мате- риалов» / сост. Е.Н. Сташевская. – Минск.: БНТУ, 2003. – 20 с. Многотомное издание История Беларуси: в 6 т. / редкол.: М.А. Костюкевич (гл. ред.) [и др.]. – Минск: Экопер- спектива, 2000–2005. – 6 т. Сборник статей, трудов Совершенствование методов гидравлических расчетов водопропускных и очистных сооружений: межвуз. науч. сб. / Саратов. гос. технич. ун-т; отв. ред. Л.И. Высоц- кий. – Саратов: СГТУ, 2002. – 98 с.: ил. Тезисы докладов и материалы конференций Современные методы проектирования машин. Расчет, конструирование и технология из- готовления: сб. трудов 1-й Междунар. конференции, Минск, 11–13 декабря 2002 г.: в 3 т. / под общ. ред. П.А. Витязя. – Минск: Технопринт, 2002. Статья из газеты Белый, С. Электроэнергетика Беларуси: настоящее и будущее /С. Белый // Рэспублiка. – 2003. – 20 снежня. – С.12. Статья из журнала Кравец, Ф. К. Динамика системы подготовки сжатого воздуха пневмопривода технологиче- ских машин /Ф.К. Кравец // Вестник Белорусского национального технического университе- та. – 2003. – № 4. – С. 44–49. Стандарт, зако- нодательные материалы Единая система стандартизации БНТУ. Курсовое проектирование / В.М. Копко [и др.]. – Утв. приказом ректора БНТУ от 18.01.2003 г. – Минск.: БНТУ, 2003. – 15 с. Конституция Республики Беларусь 1994 года (с изменениями и дополнениями): принята на респ. референдуме 24 нояб. 1996 г. в ред. решения респ. референдума 17 нояб. 2004 г. – Минск: Акад. МВД Респ. Беларусь, 2005. – 39 с. ГОСТ 8.420–2002. Государственная система обеспечения единства измерений. Государ- ственная поверочная схема для средств измерений отклонений от прямолинейности и плоскостности. – Взамен ГОСТ 8.420–81; вед. 01.09.03. – Минск: БелГИСС: Межгос. совет по стандартизации, метрологии и сертификации, 2003. – 6 с. 32 Продолжение таблицы 7 Электронные ресурсы локаль- ного доступа Российская академия наук. Отделение геологии, геофизики, геохимии и горных наук. Вестник ОГГГГН РАН [Электронный ресурс] / Объед. ин-т физики Земли им. О.Ю. Шмидта Рос. Акад. наук. – Электрон. журн. – М.: ОГГГГН РАН, 1997. – 4 дискеты. – Систем. требования: от 386; Windows; Internet-браузер кл. Netscape Navigator 3.0 и выше. – Загл. с экрана. – 4 раза в год. Internet шаг за шагом [Электронный ресурс]: [интерактив. учеб.]. – Электрон. дан. и прогр. – СПб.: ПитерКом, 1997. – 1 электрон. опт. диск (CD-ROM) + прил. (127 с.). – Систем. требова- ния: ПК от 486 DX 66 МГц; RAM 16 Мб; Windows 95; зв. плата; динамики или наушники. – Загл. с экрана. Oxford interactive encyclopedia [Электронный pecypc]. – Электрон. дан. и прогр. – [Б. м.]: The Learning Company, 1997. – 1 электрон. опт. диск (CD-ROM): зв., цв.; 12 см. – Систем. требова- ния: ПК с процессором 486+; Windows 95 или Windows 3.1; дисковод CD-ROM; зв. карта. – Загл. с этикетки диска. Электронные ресурсы удален- ного доступа Российская государственная библиотека [Электронный pecypc] / Центр информ. техноло- гий РГБ; ред. Т.В. Власенко; Web-мастер Н.В. Козлова. – Электрон. дан. – М.: Poc. гос. б- ка, 1997. – Режим доступа: http://www.rsl.ru, свободный. – Загл. с экрана. – Яз. рус., англ. Проектирование баз данных (25 курсов) [Электронный pecypc] / Интернет-Ун-т Информ. Технологий – дистанцион. образование. – Россия, 2003–2011. – Режим доступа: http://www.INTUIT.ru, свободный. – Загл. с экрана. Графический материал* представляет собой распечатанные на листах формата А4 (по одному на лист) плакаты, иллюстрирующие ход курсового проектирования. Объем графического материала не должен превышать пяти листов, быть «читабельным», не перегруженным текстовой информацией. Гра- фический материал отражает проектные решения в виде DFD- и ER-диаграмм, информационно-логические модели, схему приложения, последовательность ввода данных и т. д. На каждом листе размещается рамка и штамп, выполнен- ный по правилам инженерной графики, с подписями студента и руководителя (см. приложение Г). Графический материал нумеруется отдельно. 5.1 Правила оформления отчетного документа 1. Общий объем курсовой работы должен составлять не менее 20 и не бо- лее 50 листов формата A4, включая приложения. 2. Шрифт – Times New Roman, 12 пт, через полтора интервала. Параметры страницы: левое поле – 30 мм, правое поле – 10 мм, верхнее и нижнее поля – 20 мм. Абзацы – 15–17 мм, одинаковые по всему тексту. Выравнивание текста – по ширине. 3. Страницы пояснительной записки следует нумеровать арабскими циф- рами без точки в правом верхнем углу листа, соблюдая сквозную нумерацию по всему тексту записки (кроме листов графической части). 4. Номера страниц на титульных листах, на задании по курсовому проек- тированию и первой странице содержания не ставятся, но включаются в общую нумерацию страниц. * В курсовой работе может отсутствовать. 33 5. Наименования разделов основной части, «СОДЕРЖАНИЕ», «ВВЕДЕ- НИЕ», «ЗАКЛЮЧЕНИЕ», «СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ» следует располагать по центру строки без точки в конце и печатать прописны- ми буквами, не подчеркивая. 6. Наименования, включенные в содержание, начинаются от левого края без абзацного отступа, записываются таким же шрифтом, как в тексте записки. При- мер оформления листа содержания представлен на рисунке Д.1 в Приложении Д. 7. Каждый раздел следует начинать с нового листа. Разделы основной ча- сти нумеруются арабскими цифрами (например, «1 НОВЫЕ ВОЗМОЖНОСТИ SQL SERVER 2008» или «2 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ «АБИТУ- РИЕНТЫ») и начинаются с абзацного отступа. 8. Заголовки подразделов, пунктов и подпунктов следует начинать с абзац- ного отступа и печатать с прописной буквы, не подчеркивая, без точки в конце. Они должны иметь порядковую нумерацию в пределах раздела, подраздела или пункта (например, «1.1 Подходы к проектированию баз данных» или «2.1 Ана- лиз предметной области»). 9. Если заголовок включает несколько предложений, их разделяют точка- ми. Переносы слов в заголовках не допускаются. 10. Расстояние между текстом и следующим за ним заголовком должно со- ставлять 2 свободные строки. Расстояние между заголовками раздела и подраз- дела – 1 свободная строка. Расстояние между заголовком и следующим за ним текстом – 1 свободная строка. Пример оформления представлен на рисунке Д.2 в Приложении Д. 11. Иллюстрации (схемы, диаграммы, фрагменты программных кодов, ко- пии экранов программы) следует располагать в записке непосредственно после текста, в котором они упоминаются впервые, или на следующей странице. На все иллюстрации должны быть даны ссылки в записке. 12. Иллюстрации следует располагать по центру листа и нумеровать араб- скими цифрами нумерацией в пределах раздела, например, «Рисунок 2.1 – ER- диаграмма» (тоже по центру, указывается под рисунком без точки). Расстояние между текстом и иллюстрацией, иллюстрацией и подписью, подписью и тек- стом – 1 свободная строка). При ссылках на иллюстрации следует писать «…приводится на рисунке 2.1». Пример оформления иллюстраций представлен на рисунке Д.3 в Приложении Д. 13. Иллюстрации каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Например, «Рисунок А.3». 14. Перечисления следует печатать строчными буквами с абзацного отсту- па, разделяя их точкой с запятой, оформив их в виде нумерованного списка, ли- бо маркированного знаком дефиса, или многоуровневого, как показано ниже: 34 1. … ; или 1) … ; или – … ; или 1. … : 2. … . 2) … . – … . 1.1. … ; 1.2. … . 15. Каждый пункт перечисления оформляется отдельным абзацем. Приме- ром оформления списка является представленный на этой странице текст. 16. Формулы и вычисления следует выделять из текста в отдельную строку по центру. Выше и ниже их должно быть оставлено по одной свободной строке. 17. Каждая формула должна заканчиваться знаком препинания: запятой в случае наличия пояснений к ней, точкой с запятой в случае перечисления фор- мул либо точкой. Вычисления заканчиваются точкой. 18. Формулы в пояснительной записке следует нумеровать в пределах раздела арабскими цифрами в круглых скобках в крайнем правом положении на строке. 19. Пояснение значений формул следует приводить под формулой в той же последовательности, в которой они даны в формуле. Каждое новое значение следует давать с новой строки и заканчивать точкой с запятой (кроме последне- го значения). Первую строку начинают со слова «где» без двоеточия с абзаца, остальные строки – обычное выравнивание. Пример оформления формул пред- ставлен на рисунке Д.4 в Приложении Д. 20. Таблицы следует располагать в записке по центру страницы непосред- ственно после текста, в котором они упоминаются впервые, или на следующей странице. На все таблицы должны быть ссылки в записке. При ссылках следует писать «… по таблице 2.1». 21. Таблицы следует нумеровать арабскими цифрами нумерацией в преде- лах раздела. Таблицы должны иметь подпись, которая указывается над табли- цей и оформляется с абзаца: «Таблица 2.1 – Объекты проектирования». После названия таблицы точка не ставится. Расстояние между текстом и подписью, подписью и таблицей, таблицей и текстом – 1 свободная строка. 22. При переносе части таблицы на следующую страницу подпись, которая указывается над таблицей без абзацного отступа, имеет следующий вид: «Про- должение таблицы 2.1». Далее – шапка таблицы и ее продолжение. Пример оформления таблицы с переносом на следующую страницу представлен на ри- сунке Д.5 в Приложении Д. 23. Таблицы каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Например, «Таблица А.1 – Перечень атрибутов». 24. Список использованных источников может включать перечень стан- дартов, монографий, учебников, методических пособий, статей, тезисов докла- дов и материалов конференций, электронных ресурсов локального и удаленно- го доступов. Каждый пункт списка выравнивается по ширине окна без абзацно- го отступа. 35 25. На все использованные источники должны быть ссылки по тексту в следующем виде: <цитируемый текст> [x], где х – № источника в списке ис- пользуемых источников. 26. Каждое приложение должно начинаться с новой страницы и иметь за- головок, напечатанный с прописной буквы симметрично тексту. Над заголов- ком в правом верхнем углу прописными буквами должно быть напечатано сло- во «ПРИЛОЖЕНИЕ». Если приложений несколько, их обозначают заглавными буквами русского (белорусского) алфавита, начиная с А, за исключением букв Е, З, Й, О, Ч, Ь, Ы, Ъ, или латинского алфавита за исключением букв I и О. Название приложения записывается строчными буквами, начиная с прописной. 36 6 ЗАЩИТА КУРСОВОЙ РАБОТЫ К защите допускаются курсовые работы с визой руководителя на допуск к защите, которая ставится на титульном листе работы в срок, не позднее указан- ной на листе задания даты окончания выполненной работы. К защите допуска- ются только курсовые работы, оформленные в строгом соответствии с изло- женными выше требованиями. За содержание и оформление курсовой работы, принятые в них решения, правильность всех данных и сделанные выводы отве- чает студент – автор выполненной работы. Дата защиты определяется на заседании кафедры и проводится в соответ- ствии с расписанием, которое доводится до сведения студентов. Курсовая работа защищается на рабочей комиссии (создаваемой на кафед- ре), на которую является студент с отчетным документом. На доклад по курсо- вой работе отводится до 10 минут. Доклад должен сопровождаться иллюстра- тивным материалом (демонстрация разработки на компьютере). Для студентов специальности 1–96 01 01 «Таможенное дело» защита сопровождается разрабо- танной презентацией, где в виде тезисов излагается теоретический вопрос, про- цесс и результаты разработки базы данных. Презентация должна быть выдер- жана в строгом стиле, не быть переполненной текстовой информацией, содер- жать формулировку цели, структурированную и графическую информацию о проделанной работе в ходе курсового проектирования и выводы. После доклада студенту необходимо ответить на вопросы членов рабочей комиссии, выслушать рекомендации и замечания, высказанные членами рабо- чей комиссии и руководителем работы. Работа оценивается в 10-балльной системе с учетом качественных харак- теристик творческой деятельности. При оценке учитываются: – актуальность, значимость и практическая направленность разработки; – самостоятельность выполнения работы, уровень творчества, оригиналь- ность решения; – аргументированность предложенных решений, наличие выводов; – объем, полнота и завершенность разработки; – использование технических и программных средств; – правильность оформления пояснительной записки; – активность в процессе консультаций и обсуждений (умение задавать во- просы и отвечать на них); – балл промежуточного контроля. 37 ЛИТЕРАТУРА 1. Дейт, К.Дж. Введение в системы баз данных / К.Дж. Дейт; пер. с англ. – 7-е изд. – М.: Издат. дом «Вильямс», 2001. – 1072 с. 2. Малыхина, М.П. Базы данных: основы, проектирование, использование / М.П. Малыхина. – СПб.: БХВ-Петербург, 2004. – 512 с. 3. Разоренова, Т.Р. Управление базами данных: учебно-методич. пособие для студентов специальностей: 1–96 01 01 «Таможенное дело», 1–26 02 02 «Ме- неджмент», 1–25 01 08 «Бухгалтерский учет, анализ и аудит», 1–25 01 07 «Эко- номика и управление на предприятии», «Финансовое обеспечение и экономика боевой и хозяйственной деятельности войск (сил)» / Т.Р. Разоренова, О.В. Аль- шевская. – 2-е изд., испр. и доп. – Минск: БНТУ, 2011. – 120 с. 4. Харрингтон, Джен Л. Проектирование реляционных баз данных. Просто и доступно / Джен Л. Харрингтон; пер. с англ. – М.: Лори, 2000.– 230 с.: ил. 5. Проектирование баз данных (25 курсов) [Электронный pecypc] / Интернет- Ун-т Информ. Технологий – дистанцион. образование. – Россия, 2003 – 2011. – Режим доступа: http://www.INTUIT.ru, свободный. – Загл. с экрана. 6. Сенов, А.С. Access 2007 / А.С. Сенов. – СПб. и др.: Питер, 2008. – 266 с. 7. Проектирование и реализация баз данных Мicrosoft SQL Server 2000 / Официальное пособие Мicrosoft для самостоятельной подготовки; пер. с англ. – М.: Русская редакция, 2001. – 652 с. 8. Хернандес, Майкл Дж. SQL запросы для простых смертных: практи- ческое руководство по манипулированию данными в SQL / Майкл Дж. Хернан- дес, Джон Л. Вьескас. – М.: Лори, 2003. – 473 с. 9. Единая система стандартизации БНТУ. Курсовое проектирование / В.М. Копко [и др.]. – Утв. приказом ректора БНТУ от 18.01.2003 г. – Минск: БНТУ, 2003. – 15 с. 10. Астахова, И.Ф. SQL в примерах и задачах: учеб. пособие / И.Ф. Аста- хова, А.П. Толстобров, В.М. Мельников. – Минск: Новое знание, 2002. – 176 с. 11. Левчук, Е.А. Технологии организации, хранения и обработки данных: учеб. пособие / Е.А. Левчук. – 2-е изд. – Минск: Выш. шк., 2005. – 239 с.: ил. 38 ПРИЛОЖЕНИЯ ПРИЛОЖЕНИЕ A Титульный лист курсовой работы 39 ПРИЛОЖЕНИЕ Б Лист пояснительной записки 40 ПРИЛОЖЕНИЕ В Лист задания 41 Обратная сторона листа задания 42 ПРИЛОЖЕНИЕ Г Рамка для оформления графического материала 43 ПРИЛОЖЕНИЕ Д Примеры оформления элементов пояснительной записки Рисунок Д.1 – Пример оформления содержания пояснительной записки 44 Рисунок Д.2 – Пример расстановки разделительных строк между заголовками и текстом в пояснительной записки 45 Рисунок Д.3 – Пример размещения рисунка с подписью в тексте пояснительной записки Рисунок Д.4 – Пример размещения формулы в тексте пояснительной записки 46 Рисунок Д.5 – Пример оформления таблиц при разрыве страниц в тексте пояснительной записки ОГЛАВЛЕНИЕ ВВЕДЕНИЕ..................................................................................................................3 1 ЦЕЛИ КУРСОВОГО ПРОЕКТИРОВАНИЯ.........................................................4 2 КРАТКИЕ ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ И ТЕРМИНОЛОГИЯ...................6 2.1 Понятие предметной области ..............................................................................7 2.2 Этапы проектирования базы данных...................................................................7 2.3 Основные понятия ER-диаграмм.........................................................................8 2.4 Способы документирования ER-модели.............................................................9 2.5 Нормализация модели «сущность–связь».........................................................12 2.6 Основные объекты реляционных БД.................................................................14 2.7 Структура таблиц и целостность данных..........................................................15 3 ПОДХОДЫ К ПРОЕКТИРОВАНИЮ БАЗ ДАННЫХ.......................................20 4 ВЫПОЛНЕНИЕ ПРАКТИЧЕСКОГО РАЗДЕЛА КУРСОВОЙ РАБОТЫ........26 5 ОФОРМЛЕНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ..............................................28 5.1 Правила оформления отчетного документа......................................................32 6 ЗАЩИТА КУРСОВОЙ РАБОТЫ.........................................................................36 ЛИТЕРАТУРА...........................................................................................................37 ПРИЛОЖЕНИЯ.........................................................................................................38 Учебное издание РАЗОРЁНОВА Татьяна Ромуальдовна БАЗЫ ДАННЫХ: РАЗРАБОТКА И УПРАВЛЕНИЕ Методическое пособие для выполнения курсовой работы по дисциплинам «Информационные таможенные технологии» для студентов специальности 1–96 01 01 «Таможенное дело» и «Компьютерные информационные технологии» для студентов специальности 1–25 01 07 «Экономика и управление на предприятии» Редактор В.О. Кутас Компьютерная верстка А.Г. Занкевич Подписано в печать 01.09.2011. Формат 60×841/8. Бумага офсетная. Отпечатано на ризографе. Гарнитура Таймс. Усл. печ. л. 5,58. Уч.-изд. л. 2,18. Тираж 100. Заказ 346. Издатель и полиграфическое исполнение: Белорусский национальный технический университет. ЛИ № 02330/0494349 от 16.03.2009. Проспект Независимости, 65. 220013, Минск.