Что включает этап проектирования многотабличной базы данных
Проектирование многотабличной базы данных
«Управление общеобразовательной организацией:
новые тенденции и современные технологии»
Свидетельство и скидка на обучение каждому участнику
Конспект урока по информатике и ИКТ для учащихся 11 класса средних общеобразовательных учреждений.
Тема: «Проектирование многотабличной базы данных»
Развивающая: развитие умения анализировать, сопоставлять, сравнивать, выделять главное, приобрести опыт использования теоретических знаний и средств СУБД MS Access в реализации конкретной задачи
Воспитывающая: понимать значимость хранения и структурирования информации
виды моделей данных (иерархическая, сетевая, реляционная),
структура реляционной модели (таблица, запись, поле),
система управления базами данных СУБД,
этапы проектирования базы данных,
реляционная модель данных.
Тип урока : комбинированный.
Оборудование: интерактивная доска, проектор, презентация, компьютеры;
Семакин И.Г., Хеннер Е. К. Информатика и ИКТ. Базовый уровень. Учебник для 10-11 классов/ И.Г. Семакин, Е.К. Хеннер. – 7-е изд. – М.: БИНОМ. Лаборатория знаний,2011. – 246 с.: ил.
Семакин И.Г. «Преподавание базового курса информатики в средней школе: Методическое пособие». – 2-е изд., испр. и доп. – М.: Бином. Лаборатория знаний,2004. – 540с.
Методика преподавания информатики: учеб. пособие для студ. пед. вузов / М.П.Лапчик, И.Г.Семакин, Е.К.Хеннер. – 2-е изд., стер. – М.: Издательский центр «Академия», 2005. – 624с.
Организационный момент (2 мин).
Фронтальный опрос (4 мин)
Объяснение нового материала (15 мин)
Самостоятельная работа (15 мин)
Итог урока, рефлексия (6 мин).
Домашнее задание. (3 мин).
1. Организационный момент.
(приветствие учителем учащихся, проверка готовности класса к уроку, проверка отсутствующих, сообщение темы и целей урока). (слайд 1)
Фронтальный опрос.(слайд 2)
Что собой представляет база данных?
Для чего предназначены базы данных?
Какие существуют варианты классификации БД?
Почему реляционный вид БД является наиболее распространенным?
Что такое запись в реляционной БД?
Что такое поле в реляционной БД?
Какие бывают типы полей?
Что такое главный ключ записи?
Объяснение нового материала
Рассмотрим на конкретном примере методику проектирования много табличной базы данных.
Имеем модель данных, состоящую из трех взаимосвязанных таблиц (Слайд 3) :
Законченное учебное заведение
Оценка за экзамен 1
Оценка за экзамен 2
Оценка за экзамен 3
Эти таблицы можно рассматривать как модель данных в реляционной СУБД. Но работать с БД в таком виде неудобно, т.к. к реляционной БД предъявляется требование: минимизация избыточности данных.
Внесем изменения в таблицы (Слайд 4):
Т
аблицу АБИТУРИЕНТЫ разделим на четыре таблицы (Слайд 5):
Оценка за экзамен 1
Оценка за экзамен 2
Оценка за экзамен 3
Чтобы эти шесть таблиц представляли собой систему, между ними должны быть установлены связи. Связи позволяют определить соответствия между любыми данными в этих таблицах. Например: между фамилией абитуриента и его оценкой по математике. Благодаря этим связям становится возможным получение ответов на запросы, требующие поиска информации в нескольких таблицах одновременно.
Для указания связей между таблицами построим схему базы данных (Слайд 6).
В схеме указывается наличие связей между таблицами и типы связей.
Здесь использованы два типа связей:
При связи «один-к-одному» с одной записью в таблице связана одна запись в другой таблице. При наличии связи «один-ко-многим» одна запись в некоторой таблице связана с множеством записей в другой таблице.
Задание: Построить модель данных для данной предметной области, определив количество таблиц в БД. Установить связи и указать тип связи между таблицами. Определить для каждой таблицы поля и типы полей. Заполнить лист отчета.
В таблицах должна содержаться следующая информация: название отделения, ФИО заведующего отделением, число больничных коек в отделении, телефон заведующего, ФИО врача, категория врача, ФИО больного, дата рождения больного, адрес больного, место работы, должность, диагноз при поступлении, номер палаты, первичный ли больной (впервые ли поступил в стационар с данным диагнозом), дата выписки, дата состояния, температура, общее состояние (тяжелое, удовлетворительное и т.п.), лечение (список лекарств и процедур).
В таблицах должна содержаться следующая информация: название отдела, ФИО начальника отдела, номер кабинета начальника, телефон начальника отдела, код рабочей группы, ФИО руководителя группы, номер кабинета руководителя, телефон руководителя, количество сотрудников в группе, ФИО сотрудника, дата рождения, адрес, образование, семейное положение, количество детей, дата поступления в организацию, имеет ли награды, имеет ли взыскания, дата назначения на должность, название должности, зарплата.
Итог урока, рефлексия
Домашнее задание: § 32, с. 178 №1,2, 3 (б)
Проектирование многотабличной базы данных
Урок 8. Информатика 11 класс ФГОС
В данный момент вы не можете посмотреть или раздать видеоурок ученикам
Чтобы получить доступ к этому и другим видеоурокам комплекта, вам нужно добавить его в личный кабинет, приобрев в каталоге.
Получите невероятные возможности
Конспект урока «Проектирование многотабличной базы данных»
На данном уроке мы с вами научимся создавать структуру базы данных в виде таблиц, узнаем, какие отношения и связи бывают между таблицами, построим схему данных и многое другое.
Чтобы узнать, как правильно проектировать многотабличную базу данных, мы рассмотрим этот процесс на примере. Для этого нам необходимо вернуться к примеру моделирования работы кредитного отдела банка.
Для начала вспомним модель данных, которая состояла из трёх взаимосвязанных таблиц. Она выглядит следующим образом.
Данные таблицы представляют собой модель данных в реляционной СУБД. Но для удобной работы с базой данных, необходимо соблюдать некоторые требования.
Одно и главное из них – это отсутствие избыточности данных. Это говорит о том, что нужно избегать лишних данных при построении базы данных, так как это приводит к лишнему расходу памяти. При выполнении этого требования можно сократить не только потребность в памяти компьютера, но и время поиска и обработки данных.
Видимый недостаток наших таблиц в том, что многократно повторяются значения полей в разных записях. Например, Вид кредита будет повторяться в 50 записях для 50 кредиторов, которые подали документы на кредит. Для удобства можно в таблице «Кредитование населения с учётом плана» добавить поле «Код кредита», а в таблице «Вид кредитования» поле «Вид кредита» заменить на поле «Код кредита». Таким образом, вид кредита будет записан только единожды, а в анкетах кредиторов будет стоять код. Аналогично изменим поле «Вид кредита» на поле «Код кредита» в таблице «Кредиторы». А также изменим название таблицы «кредитование населения с учётом плана» на «Кредитование».
После изменения получим следующее.
Далее следует обратить внимание на таблицу «кредиторы». Она слишком большая и не удобная для работы. Можно разбить её на несколько таблиц поменьше. Получим следующее:
Такие таблицы более удобны.
В таблице «Анкета» содержатся данные о кредиторе. В таблице «Кредит» содержатся данные о виде кредита, сумме и отметке выдачи. А в таблице «Документы» содержится информация о поданных документах на кредит.
У нас получилось пять таблиц. Давайте представим их в строчном виде. Подчёркнутые поля будут обозначать ключевое поле.
Для представления системы, все наши пять таблиц должны быть связаны между собой.
Если внимательно посмотреть на наши таблицы в строчном виде, то мы можем увидеть связи. Например, две первые таблицы имеют общее поле «Код кредита», а третья, четвёртая и пятая – регистрационный номер.
Связи помогают определить соответствия между любыми данными в этих таблицах, например, между фамилией кредитора и документами, которые он подал для кредитования. Благодаря этим связям можно получить ответы на запросы, которые требуют поиска информации в нескольких таблицах одновременно.
Следующее, с чем мы должны с вами познакомиться – это схема базы данных. Она создаётся для указания связей между таблицами. В схеме отображается наличие и типы связей между таблицами.
Если отобразить связи для нашей базы данных, то мы получим следующее:
Существует такие типы связей: «один к одному» и «один ко многим».
Чтобы показать связь «один ко многим», добавим ещё одну таблицу «Перечень документов», которая будет состоять из двух полей: «Номер документа» и «Документ». В поле «Документ» будут перечислены все возможные документы для всех видов кредита.
Связь «один к одному» обозначается двунаправленной стрелкой, а связь «один ко многим» – одинарной стрелкой в одну сторону и двойной в другую. При связи «один к одному» с одной записью в таблице связана одна запись в другой таблице. Например, одна запись о кредиторе связана с одной записью о поданных им документах.
Связь «один ко многим» означает, что одна запись в одной таблице связана с несколькими записями в другой. Например, с одним видом кредита связано несколько видов документов.
Что же такое целостность данных?
Целостность данных – это свойство базы данных, которое обеспечивается поддерживанием организации связи между таблицами базы данных, которое осуществляет СУБД.
Система не позволит, чтобы одноименные поля в разных связанных между собой таблицах имели разные значения. Поэтому система автоматически контролирует ввод данных.
В связанных таблицах можно устанавливать режим каскадной замены. Это говорит о том, что при изменении значения поля в одной таблице, по которому установлена связь, будут автоматически изменены значения одноименных полей в других таблицах.
Если же установить режим каскадного удаления, то достаточно удалить запись из одной таблицы, чтобы связанные записи исчезли изо всех остальных таблиц.
На данном этапе проектирование базы данных подошло к концу.
Подведём итоги нашего урока.
Главное требование для удобной работы с базой данных – это отсутствие избыточности данных.
· Связи помогают определить соответствия между любыми данными в этих таблицах.
· Схема базы данных создаётся для указания связей между таблицами.
· Типы связей бывают следующих видов: «один к одному» и «один ко многим».
Проектирование многотабличной базы данных
Раздел программы: Технологии использования и разработки информации-онных систем. На уроке ученики освоят новые возможности СУБД MS Access.
Просмотр содержимого документа
«Проектирование многотабличной базы данных»
Урок на тему: «Проектирование многотабличной базы данных»
Раздел программы: Технологии использования и разработки информации-онных систем.
виды моделей данных (иерархическая, сетевая, реляционная),
структура реляционной модели (таблица, запись, поле),
система управления базами данных СУБД,
этапы проектирования базы данных,
реляционная модель данных.
Обучающая: освоить новые возможности СУБД MS Access, приблизить овладение СУБД MS Access к профессиональному уровню
Развивающая: развитие умения анализировать, сопоставлять, сравнивать, выделять главное, приобрести опыт использования теоретических знаний и средств СУБД MS Access в реализации конкретной задачи
Воспитывающая: понимать значимость хранения и структурирования информации
Тип урока: урок изучения нового материала.
Вид урока: комбинированный урок.
интерактивная доска, проектор;
Последовательность этапов урока:
Организационный момент, сообщение темы и целей урока (2 мин).
Фронтальный опрос (4 мин)
Объяснение нового материала (15 мин)
Самостоятельная работа (15 мин)
Итог урока, рефлексия (6 мин).
Домашнее задание. (3 мин).
Организационный момент. Сообщение темы и целей урока. (Слайд 1)
Что собой представляет база данных?
Для чего предназначены базы данных?
Какие существуют варианты классификации БД?
Почему реляционный вид БД является наиболее распространенным?
Что такое запись в реляционной БД?
Что такое поле в реляционной БД?
Какие бывают типы полей?
Что такое главный ключ записи?
Объяснение нового материала
Рассмотрим на конкретном примере методику проектирования много табличной базы данных.
Имеем модель данных, состоящую из трех взаимосвязанных таблиц (Слайд 3):
Законченное учебное заведение
Оценка за экзамен 1
Оценка за экзамен 2
Оценка за экзамен 3
Эти таблицы можно рассматривать как модель данных в реляционной СУБД. Но работать с БД в таком виде неудобно, т.к. к реляционной БД предъявляется требование: минимизация избыточности данных.
Внесем изменения в таблицы:
Таблицу АБИТУРИЕНТЫ разделим на четыре таблицы:
Оценка за экзамен 1
Оценка за экзамен 2
Оценка за экзамен 3
Чтобы эти шесть таблиц представляли собой систему, между ними должны быть установлены связи. Связи позволяют определить соответствия между любыми данными в этих таблицах. Например: между фамилией абитуриента и его оценкой по математике. Благодаря этим связям становится возможным получение ответов на запросы, требующие поиска информации в нескольких таблицах одновременно.
Для указания связей между таблицами построим схему базы данных.
В схеме указывается наличие связей между таблицами и типы связей.
Здесь использованы два типа связей:
При связи «один-к-одному» с одной записью в таблице связана одна запись в другой таблице. При наличии связи «один-ко-многим» одна запись в некоторой таблице связана с множеством записей в другой таблице.
Задание: Построить модель данных для данной предметной области, определив количество таблиц в БД. Установить связи и указать тип связи между таблицами. Определить для каждой таблицы поля и типы полей. Заполнить лист отчета.
В таблицах должна содержаться следующая информация: название отделения, ФИО заведующего отделением, число больничных коек в отделении, телефон заведующего, ФИО врача, категория врача, ФИО больного, дата рождения больного, адрес больного, место работы, должность, диагноз при поступлении, номер палаты, первичный ли больной (впервые ли поступил в стационар с данным диагнозом), дата выписки, дата состояния, температура, общее состояние (тяжелое, удовлетворительное и т.п.), лечение (список лекарств и процедур).
В таблицах должна содержаться следующая информация: название отдела, ФИО начальника отдела, номер кабинета начальника, телефон начальника отдела, код рабочей группы, ФИО руководителя группы, номер кабинета руководителя, телефон руководителя, количество сотрудников в группе, ФИО сотрудника, дата рождения, адрес, образование, семейное положение, количество детей, дата поступления в организацию, имеет ли награды, имеет ли взыскания, дата назначения на должность, название должности, зарплата.
Итог урока, рефлексия
Домашнее задание:§32, с. 178 №1,2, 3 (б)
Информатика и ИКТ. Базовый уровень: учебник для 10-11 классов / И.Г. Семакин, Е.К. Хеннер.- М.: Бином. Лаборатория знаний, 2008.
Информатика и ИКТ. Базовый уровень: практикум для 10-11 классов / И.Г. Семакин, Е.К. Хеннер., Т.Ю. Шеина.- М.: Бином. Лаборатория знаний, 2008.
Проектирование баз данных, его этапы и задачи.
Содержание:
Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.
Невозможно создать БД без подробного ее описания, также как и невозможно сделать какое-либо сложное изделие без чертежа и подробного описания технологий его изготовления. Другими словами, нужен проект. Проектом принято считать эскиз некоторого устройства, который в дальнейшем будет воплощен в реальность. Процесс проектирования БД представляет собой процесс переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели. Конечной целью проектирования является построение конкретной БД. Очевидно, что процесс проектирования сложен и поэтому имеет смысл разделить его на логически завершенные части – этапы.
При проектировании таблиц рекомендуется руководствоваться следующими основными принципами:
Основные задачи проектирования баз данных:
Основные этапы проектирования баз данных:
Концептуальное (инфологическое) проектирование.
Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.
Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.
Чаще всего концептуальная модель базы данных включает в себя:
Инфологическую модель можно создавать с помощью нескольких методов и подходов:
Поскольку использование метода «сущность-связь» является комбинированным способом проектирования на данном этапе, он чаще других становится приоритетным.
Локальные представления при методическом разделении должны, по возможности, включать в себя информацию, которой бы хватило для решения обособленной задачи или для обеспечения запросов какой-то группы потенциальных пользователей. Каждая из этих областей содержит порядка 6-7 сущностей и соответствует какому-либо отдельному внешнему приложению.
Зависимость сущностей отражается в разделении их на сильные (базовые, родительские) и слабые (дочерние). Сильная сущность (например, читатель в библиотеке) может существовать в БД сама по себе, а слабая сущность (например, абонемент этого читателя) «привязывается» к сильной и отдельно не существует.
Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:
После этого производится спецификация атрибута, спецификация связей в локальном представлении (с разделением на факультативные и обязательные) и объединение локальных представлений. При числе локальных областей до 4-5 их можно объединить за один шаг. В случае увеличения числа бинарное объединение областей происходит в несколько этапов.
В ходе этого и других промежуточных этапов находит своё отражение итерационная природа проектирования, выражающаяся здесь в том, что для устранения противоречий необходимо возвращаться на этап моделирования локальных представлений для уточнения и изменения (например, для изменения одинаковых названий семантически разных объектов или для согласования атрибутов целостности на одинаковые атрибуты в разных приложениях).
Логическое (даталогическое) проектирование.
Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Логическая структура БД должна соответствовать логической модели предметной области и учитывать связь модели данных с поддерживаемой СУБД. Поэтому этап начинается с выбора модели данных, где важно учесть её простоту и наглядность.
Предпочтительнее, когда естественная структура данных совпадает с представляющей её моделью. Так, например, если в данные представлены в виде иерархической структуры, то и модель лучше выбирать иерархическую. Однако на практике такой выбор чаще определяется системой управления БД, а не моделью данных. Поэтому концептуальная модель фактически транслируется в такую модель данных, которая совместима с выбранной системой управления БД.
Здесь тоже находит отражение природа проектирования, которая допускает возможность (или необходимость) вернуться к концептуальной модели для её изменения в случае, если отражённые там взаимосвязи между объектами (или атрибуты объектов) не удастся реализовать средствами выбранной СУБД.
По завершению этапа должны быть сформированы схемы баз данных обоих уровней архитектуры (концептуального и внешнего), созданные на языке определения данных, поддерживаемых выбранной СУБД.
Схемы базы данных формируются с помощью одного из двух разнонаправленных подходов:
Второй подход предполагает определение ряда высокоуровневых сущностей и их взаимосвязей с последующей детализацией до нужного уровня, что и отражает, например, модель, созданная на основе метода «сущность-связь». Но на практике оба подхода, как правило, комбинируются.
Физическое проектирование.
Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. д.
На следующем этапе физического проектирования БД логическая структура отображается в виде структуры хранения БД, то есть увязывается с такой физической средой хранения, где данные будут размещены максимально эффективно. Здесь детально расписывается схема данных с указанием всех типов, полей, размеров и ограничений. Помимо разработки индексов и таблиц, производится определение основных запросов.
Построение физической модели сопряжено с решением во многом противоречивых задач:
Вторая задача вступает в конфликт с первой, поскольку, например:
Всё это увеличивает размер базы данных, поэтому проектировщик ищет разумный баланс, при котором задачи решаются оптимально путём грамотного размещения данных в пространстве памяти, но не за счёт средств защиты базы дынных, куда входит как защита от несанкционированного доступа, так и защита от сбоев.
Для завершения создания физической модели проводят оценку её эксплуатационных характеристик (скорость поиска, эффективность выполнения запросов и расхода ресурсов, правильность операций). Иногда этот этап, как и этапы реализации базы данных, тестирования и оптимизации, а также сопровождения и эксплуатации, выносят за пределы непосредственного проектирования БД.
Выбор системы управления и программных средств БД.
От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:
Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.