Размещено на http://www.allbest.ru/

• СОДЕРЖАНИЕ
• ВВЕДЕНИЕ
• 1. ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ ДАННЫМИ В ИНФОРМАЦИОННЫХ СИСТЕМАХ. ОРГАНИЗАЦИЯ ДАННЫХ И ТЕХНОЛОГИЯ УПРАВЛЕНИЯ ДАННЫХ
• 2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ РЫНКА АВТОМОБИЛЕЙ
• 2.1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
• 2.2 ПОСТРОЕНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ БАЗЫ ДАННЫХ РЫНКА АВТОМОБИЛЕЙ
• 2.3 РАЗРАБОТКА ЛОГИЧЕСКОЙ И ФИЗИЧЕСКОЙ МОДЕЛИ БАЗЫ ДАННЫХ
• 2.4 ПОСТРОЕНИЕ ФИЗИЧЕСКОЙ МОДЕЛИ ДАННЫХ РЫНКА АВТОМОБИЛЕЙ НА ЯЗЫКЕ SQL СРЕДСТВАМИ СУБД MYSQL
• 2.5 РЕАЛИЗАЦИЯ ПРОЕКТИРУЕМОЙ СХЕМЫ БАЗЫ ДАННЫХ РЫНКА АВТОМОБИЛЕЙ С ИСПОЛЬЗОВАНИЕМ WEB-ИНТЕРФЕЙСА, СОЗДАННОГО НА ЯЗЫКЕ ПРОГРАММИРОВАНИЯ PHP
• 3. ОБОСНОВАНИЕ И РАСЧЕТ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ И ВНЕДРЕНИЯ ИНТЕРНЕТ-МАГАЗИНА АВТОМОБИЛЕЙ
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
• ПРИЛОЖЕНИЕ 1.
• ПРИЛОЖЕНИЕ 2.
• ПРИЛОЖЕНИЕ 3.
• ПРИЛОЖЕНИЕ 4.
• ВВЕДЕНИЕ
• Базы данных являются одним из основных компонентов систем всех уровней и типов. Также и на примере создания сайта мы убедимся в необходимости продуманного создания не только самих таблиц с данными, но и связей между ними, удобного и понятного интерфейса. Здесь от успешности выполнения поставленных задач будет зависит насколько прибыльным будет работа всего проекта.
• Исходя из актуальности темы данной курсовой работы выделим цель работы: создать прототип интернет-магазина торгующего автомобилями.
• Задачами данной курсовой работы являются:
• 1. Ответ на теоретический вопрос: «Организация управления данными в информационных системах. Организация данных и технология управления данных в АИС»
• 2. Проектирование и создание базы данных в СУБД MYSQL для интернет-магазина автомобилей.
• 3. Разработка Web интерфейса сайта на языке программирования PHP, который будет динамически создавать страницы и работать с созданной базой данных.
• 4. Расчет экономической эффективности внедрения интернет-маганзина автомобилей.
• Курсовая работа имеет следующую структуру: введение, три главы, заключение, список использованных источников, четыре приложения. В первой главе в реферативной форме дается ответ на теоретический вопрос, во второй содержатся материалы по описанию и анализу предметной области, разработке концептуальной и логической моделей базы данных с последующей реализацией их в интерактивной среде Интернет с использованием web-интерфейса. Также во втором разделе описан процесс построения физической модели базы данных на языке SQL, и активизация созданного сайта помощью языка программирования PHP. В третье части курсовой работы рассчитывается экономическая эффективность разработки и внедрения интернет-магазина, рассчитывается на каком месяце данный интернет-магазин окупится и будет приносить прибыль.
• При написании работы были использована литература таких авторов как Джена Л. Харрингтона, Корнеева В. В., Гареева А. Ф., Малыхина М.П. также были использованы интернет ресурсы некоторых сайтов.
• программирование сайт интерфейс магазин
• 1. ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ ДАННЫМИ В ИНФОРМАЦИОННЫХ СИСТЕМАХ. ОРГАНИЗАЦИЯ ДАННЫХ И ТЕХНОЛОГИЯ УПРАВЛЕНИЯ ДАННЫХ В АИС
• На начальном этапе использования вычислительной техники для управления информацией проблемы структуризации данных решались индивидуально в каждой информационной системе. Производились необходимые надстройки над файловыми системами (библиотеки программ), подобно тому, как это делается в компиляторах, редакторах и т.д.
• Но поскольку информационные системы требуют сложных структур данных, эти дополнительные индивидуальные средства управления данными являлись существенной частью информационных систем и практически повторялись от одной системы к другой. Стремление выделить и обобщить общую часть информационных систем, ответственную за управление сложно структурированными данными, явилось, на наш взгляд, первой побудительной причиной создания СУБД. Очень скоро стало понятно, что невозможно обойтись общей библиотекой программ, реализующей над стандартной базовой файловой системой более сложные методы хранения данных.
• Предположим, что мы хотим реализовать простую информационную систему, поддерживающую учет сотрудников некоторой организации. Система должна выполнять следующие действия: выдавать списки сотрудников по отделам, поддерживать возможность перевода сотрудника из одного отдела в другой, приема на работу новых сотрудников и увольнения работающих. Для каждого отдела должна поддерживаться возможность получения имени руководителя этого отдела, общей численности отдела, общей суммы выплаченной в последний раз зарплаты и т.д. Для каждого сотрудника должна поддерживаться возможность выдачи номера удостоверения по полному имени сотрудника, выдачи полного имени по номеру удостоверения, получения информации о текущем соответствии занимаемой должности сотрудника и о размере его зарплаты [1, c 55].
• Предположим, что мы решили основывать эту информационную систему на файловой системе и пользоваться при этом одним файлом, расширив базовые возможности файловой системы за счет специальной библиотеки функций. Поскольку минимальной информационной единицей в нашем случае является сотрудник, естественно потребовать, чтобы в этом файле содержалась одна запись для каждого сотрудника. Какие поля должна содержать такая запись? Полное имя сотрудника (СОТР_ИМЯ), номер его удостоверения (СОТР_НОМЕР), информацию о его соответствии занимаемой должности (для простоты, "да" или "нет") (СОТР_СТАТ), размер зарплаты (СОТР_ЗАРП), номер отдела (СОТР_ОТД_НОМЕР). Поскольку мы хотим ограничиться одним файлом, та же запись должна содержать имя руководителя отдела (СОТР_ОТД_РУК).
• Функции нашей информационной системы требуют, чтобы обеспечивалась возможность многоключевого доступа к этому файлу по уникальным ключам (недублируемым в разных записях) СОТР_ИМЯ и СОТР_НОМЕР. Кроме того, должна обеспечиваться возможность выбора всех записей с общем значением СОТР_ОТД_НОМЕР, то есть доступ по неуникальному ключу. Для того, чтобы получить численность отдела или общий размер зарплаты, каждый раз при выполнении такой функции информационная система должна будет выбрать все записи о сотрудниках отдела и посчитать соответствующие общие значения.
• Таким образом мы видим, что даже для такой простой системы ее реализация на базе файловой системы, во-первых, требует создания достаточно сложной надстройки для многоключевого доступа к файлам, и, во-вторых, вызывает требование существенной избыточности хранения (для каждого сотрудника одного отдела повторяется имя руководителя) и выполнение массовой выборки и вычислений для получения суммарной информации об отделах. Кроме того, если в ходе эксплуатации системы нам захочется, например, выдавать списки сотрудников, получающих заданную зарплату, то придется либо полностью просматривать файл, либо реструктуризовывать его, объявляя ключевым поле СОТР_ЗАРП [1, c 72].
• Первое, что приходит на ум, - это поддерживать два многоключевых файла: СОТРУДНИКИ и ОТДЕЛЫ. Первый файл должен содержать поля СОТР_ИМЯ, СОТР_НОМЕР, СОТР_СТАТ, СОТР_ЗАРП и СОТР_ОТД_НОМЕР, а второй - ОТД_НОМЕР, ОТД_РУК, ОТД_СОТР_ЗАРП (общий размер зарплаты) и ОТД_РАЗМЕР (общее число сотрудников в отделе). Большинство неудобств, перечисленных в предыдущем абзаце, будут преодолены. Каждый из файлов будет содержать только недублируемую информацию, необходимости в динамических вычислениях суммарной информации не возникает. Но заметим, что при таком переходе наша информационная система должна обладать некоторыми новыми особенностями, сближающими ее с СУБД.
• Прежде всего, система должна теперь знать, что она работает с двумя информационно связанными файлами (это шаг в сторону схемы базы данных), должна знать структуру и смысл каждого поля (например, что СОТР_ОТД_НОМЕР в файле СОТРУДНИКИ и ОТД_НОМЕР в файле ОТДЕЛЫ означают одно и то же), а также понимать, что в ряде случаев изменение информации в одном файле должно автоматически вызывать модификацию во втором файле, чтобы их общее содержимое было согласованным. Например, если на работу принимается новый сотрудник, то необходимо добавить запись в файл СОТРУДНИКИ, а также соответствующим образом изменить поля ОТД_ЗАРП и ОТД_РАЗМЕР в записи файла ОТДЕЛЫ, описывающей отдел этого сотрудника.
• Понятие согласованности данных является ключевым понятием баз данных. Фактически, если информационная система (даже такая простая, как в нашем примере) поддерживает согласованное хранение информации в нескольких файлах, можно говорить о том, что она поддерживает базу данных. Если же некоторая вспомогательная система управления данными позволяет работать с несколькими файлами, обеспечивая их согласованность, можно назвать ее системой управления базами данных. Уже только требование поддержания согласованности данных в нескольких файлах не позволяет обойтись библиотекой функций: такая система должна иметь некоторые собственные данные (метаданные) и даже знания, определяющие целостность данных [1, c 78].
• Но это еще не все, что обычно требуют от СУБД. Во-первых, даже в нашем примере неудобно реализовывать такие запросы как "выдать общую численность отдела, в котором работает Петр Иванович Сидоров". Было бы гораздо проще, если бы СУБД позволяла сформулировать такой запрос на близком пользователям языке. Такие языки называются языками запросов к базам данных. Например, на языке SQL наш запрос можно было бы выразить в форме:
• SELECT ОТД_РАЗМЕР
• FROM СОТРУДНИКИ, ОТДЕЛЫ
• WHERE СОТР_ИМЯ = "ПЕТР ИВАНОВИЧ СИДОРОВ"
• AND СОТР_ОТД_НОМЕР = ОТД_НОМЕР
• Таким образом, при формулировании запроса СУБД позволит не задумываться о том, как будет выполняться этот запрос. Среди ее метаданных будет содержаться информация о том, что поле СОТР_ИМЯ является ключевым для файла СОТРУДНИКИ, а ОТД_НОМЕР - для файла ОТДЕЛЫ, и система сама воспользуется этим. Если же возникнет потребность в получении списка сотрудников, не соответствующих занимаемой должности, то достаточно предъявить системе запрос
• SELECT СОТР_ИМЯ, СОТР_НОМЕР
• FROM СОТРУДНИКИ
• WHERE СОТР_СТАТ = "НЕТ",
• и система сама выполнит необходимый полный просмотр файла СОТРУДНИКИ, поскольку поле СОТР_СТАТ не является ключевым.
• Далее, представьте себе, что в нашей первоначальной реализации информационной системы, основанной на использовании библиотек расширенных методов доступа к файлам, обрабатывается операция регистрации нового сотрудника. Следуя требованиям согласованного изменения файлов, информационная система вставила новую запись в файл СОТРУДНИКИ и собиралась модифицировать запись файла ОТДЕЛЫ, но именно в этот момент произошло аварийное выключение питания. Очевидно, что после перезапуска системы ее база данных будет находиться в рассогласованном состоянии. Потребуется выяснить это (а для этого нужно явно проверить соответствие информации с файлах СОТРУДНИКИ и ОТДЕЛЫ) и привести информацию в согласованное состояние. Настоящие СУБД берут такую работу на себя. Прикладная система не обязана заботиться о корректности состояния базы данных [3, c 112].
• Наконец, представим себе, что мы хотим обеспечить параллельную (например, многотерминальную) работу с базой данных сотрудников. Если опираться только на использование файлов, то для обеспечения корректности на все время модификации любого из двух файлов доступ других пользователей к этому файлу будет блокирован (вспомните возможности файловых систем для синхронизации параллельного доступа). Таким образом, зачисление на работу Петра Ивановича Сидорова существенно затормозит получение информации о сотруднике Иване Сидоровиче Петрове, даже если они будут работать в разных отделах. Настоящие СУБД обеспечивают гораздо более тонкую синхронизацию параллельного доступа к данным.
• Таким образом, СУБД решают множество проблем, которые затруднительно или вообще невозможно решить при использовании файловых систем. При этом существуют приложения, для которых вполне достаточно файлов; приложения, для которых необходимо решать, какой уровень работы с данными во внешней памяти для них требуется, и приложения, для которых безусловно нужны базы данных.
• К функций СУБД принято относить следующие:
• Непосредственное управление данными во внешней памяти
• Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД.
• Управление буферами оперативной памяти
• СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов [4, c 35].
• Заметим, что существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
• Управление транзакциями
• Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД [3, c 137].
• То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег).
• С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
• Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
• Журнализация
• Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
• Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
• Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода [2, c 218].
• Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
• Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
• При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.
• Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным [4, c 155].
• Поддержка языков БД
• Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Мы рассмотрим более подробно языки ранних СУБД в следующей лекции.
• В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). В нескольких лекциях этого курса язык SQL будет рассматриваться достаточно подробно, а пока мы перечислим основные функции реляционной СУБД, поддерживаемые на "языковом" уровне (т.е. функции, поддерживаемые при реализации интерфейса SQL).
• Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов [4, c 170].
• Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
• Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
• Типовая организация современной СУБД
• Естественно, организация типичной СУБД и состав ее компонентов соответствует рассмотренному нами набору функций. Напомним, что мы выделили следующие основные функции СУБД:
• управление данными во внешней памяти;
• управление буферами оперативной памяти;
• управление транзакциями;
• журнализация и восстановление БД после сбоев;
• поддержание языков БД.
• Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.
• Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти компоненты выделяются явно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Как можно было понять из первой части этой лекции, функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы [4, c 180].
• Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем (а это, как правило, SQL) являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия (вспомните примеры из первой лекции). Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Применяются достаточно сложные методы оптимизации операторов, которые мы подробно рассмотрим в следующих лекциях. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения, представляющей собой, по сути дела, интерпретатор этого внутреннего языка.
• Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра [4, c 193].

2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ РЫНКА АВТОМОБИЛЕЙ

2.1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

Каждый пользователь имеет дело с представлением предметной области, выраженным в наиболее удобной для него форме. Внешнее представление содержит только те сущности, атрибуты и связи предметной области, которые интересны пользователю.

Помимо этого, различные представления могут по-разному отображать одни и те же данные. Например, один пользователь может просматривать даты в формате (день, месяц, год), а другой - в формате (год, месяц, день). Некоторые представления могут включать производные или вычисляемые данные, которые не хранятся в базе данных как таковые, а создаются по мере надобности. Представления могут также включать комбинированные или производные данные из нескольких объектов.

Сделаем анализ предметной области интернет - магазинов, которые занимаются продажей автомобилей. Обычно, интеренет-магазин - это база данных. В результате поиска были найдены следующие магазины: http://avto.by/, http://www.motor.ru/, http://audi.ru/.

Анализ этих интернет-магазинов показал, что на белорусском рынке уже существуют магазины автомобилей у которых есть свои покупатели. Такие магазины посещают примерно 5000 человек в месяц.

Наши объекты концептуальной модели базы данных будет: автомобиль, который продается в магазине, покупатель, который покупает данный автомобиль, поставщик, который продает автомобиль, счет по которому производится оплата автомобиля.

Для интернет-магазина, который продают автомобили можно выделить следующие сущности: марка автомобиля (vid), наименование автомобиля (модель) (product), покупатели (customer), покупка (buying), партнер (partners).

2.2 ПОСТРОЕНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ БАЗЫ ДАННЫХ РЫНКА АВТОМОБИЛЕЙ

2.3 РАЗРАБОТКА ЛОГИЧЕСКОЙ И ФИЗИЧЕСКОЙ МОДЕЛИ БАЗЫ ДАННЫХ

Логический уровень -- это абстрактный взгляд на данные, когда данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

Так как в нашем случае присутствует связь , то реализация такой связи в СУБД реляционного типа затруднительна, поэтому, нужно ввести новую сущность, назовем ее buyingpok.

Размещено на http://www.allbest.ru/

Рис. 2.1 Введение новой сущности buyingclothes

Рис. 2.2 ER-диаграмма логической модели базы данных

Физическая модель данных строится на базе логической модели и описывает данные уже средствами конкретной СУБД. Отношения, разработанные на стадии логического моделирования, преобразуются в таблицы, атрибуты в столбцы, домены в типы данных, принятых в выбранной конкретной СУБД. На этапах логического и физического моделирования, как правило, используется стандарт IDEF1X и case-средства ERWin или SmartER. Указанные инструментальные средства проектирования поддерживают несколько десятков наиболее популярных СУБД. Результатом физического моделирования является генерация программного кода базы данных на соответствующем выбранной СУБД диалекте структурированного языка запросов SQL.

Физическая модель содержит описание структур данных и организации отдельных файлов, используемых для хранения данных в запоминающих устройствах. На этом уровне осуществляется взаимодействие СУБД с методами доступа операционной системы с целью размещения данных на запоминающих устройствах, создания индексов, извлечения данных и т.д. На внутреннем уровне хранится следующая информация: сведения о распределении дискового пространства для хранения данных и индексов; описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных); сведения о размещении записей; сведения о сжатии данных и выбранных методах их шифрования.

2.4 ПОСТРОЕНИЕ ФИЗИЧЕСКОЙ МОДЕЛИ ДАННЫХ РЫНКА АВТОМОБИЛЕЙ НА ЯЗЫКЕ SQL СРЕДСТВАМИ СУБД MYSQL

3. ОБОСНОВАНИЕ И РАСЧЕТ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ И ВНЕДРЕНИЯ ИНТЕРНЕТ-МАГАЗИНА АВТОМОБИЛЕЙ

Экономический расчет начинаем с расчета затрат.

Затраты подразделяются на:

затраты на первоначальный анализ и планирование;

затраты на приобретение технических средств;

затраты на приобретение программных средств;

затраты на установку и монтаж оборудования;

затраты на разработку и создание Web-страниц;

прочие затраты.

Затраты на первоначальный анализ и планирование составят 200 у.е.(заработная плата специалисту за проведенный анализ и планирование). Затраты на приобретение технических и программных средств составляют 1500 у.е. и 3000 у.е., в сумме 4500 у.е.

Затраты на установку и монтаж определяем по общепринятым нормативам, в процентах от стоимости технических средств, норматив затрат - 3%

Км =0.03*1500 = 45 у.е.

Затраты на разработку и создание Web-страниц подразделяются по следующим статьям:

затраты на потребляемую электроэнергию;

расходы на оплату труда (основная и дополнительная заработная плата);

начисления на заработную плату.

В табл. 3.1 приведены данные, необходимые для расчета затрат на разработку и создание Web-страниц.

Таблица 3.1. Исходные данные

Затраты на потребляемую электроэнергию определим по следующей формуле:

Зэл = U*M*Tp*t (1)

где Ц -- стоимость Вт злектроэнергии; М -- потребляемая мощ-ть одной ПЭВМ; t - время работы одной ПЭВМ в день; Тр - продолжительность разработки.

Разработка будет осуществляться в ноябре.

Фэ = Дн - Дв. (2)

где Дн - количество дней в ноябре;

Дв - количество выходных и праздничных дней. Фэ = 30-11 = 19.

Тогда

Зэл = 19*8*0.2*0.1 = 3,04 у.е.

Затраты по оплате труда определяем по формуле:

Зот = (з/п+з/п*Нд)*Тр*Ч Зот = (400+400*0.4)*1*3 = 1680 у.е. (3)

Отчислениями с заработной платы являются:

отчисления в фонд социальной защиты населения (35%)

1680*0.35 =588 у.е;

отчисления на соцстрах (1%) 1680*0.01 = 16,8 у.е.

Итого: 588+16,8=604,8 у.е..

Всего 1680+ 604,8 + 3,04 = 2287,84 у.е.

В прочие затраты включаем затраты на подключение к сети Internet единовременно 15 у.е.(будем использовать доступ по выделенной линии со скоростью "256/256" (скорость прием/передача 256/256Кбит/с (byfly.by)) (60 у.е. в месяц), затраты на регистрацию сервера ( 15 у.е.)).

Итого, прочие затраты будут составлять: 15+60+15=90 у.е.

Общая сумма капитальных затрат приведена в табл. 3.2.

Таблица 3.2. Капитальные затраты

Расчет эксплутационных затрат для ЭМ

Эксплуатационные затраты представляют собой сумму затрат, связанных с эксплуатацией электронного магазина. Они включают следующие статьи затрат:

1. амортизационные отчисления;

2. затраты на потребляемую электроэнергию;

3. затраты на послегарантийный ремонт оборудования;

4. затраты на оплату труда;

5. начисления на заработную плату;

6. абонентскую плату за доступ к сети Internet и за использование IP-адреса;

7. расходы на проведение рекламной кампании;

8. расходы по доставке товара покупателю;

9. затраты на расходные материалы.

Расчет амортизационных отчислений производится по формуле:

За = Кп*На, (4)

где За - сумма амортизационных отчислений,

Кп - затраты на приобретение оборудования,

На - норма амортизации.

Норму амортизации возьмем в размере 12,5%, сумма амортизационных отчислений составит:

За = 4500*0,125 = 562,5 у.е.,

Затраты на потребляемую электроэнергию определим по формуле:

Зэл = Ц*М*1*Фэ, (5)

где Ц - стоимость 1 кВт электроэнергии (0,2 у.е), М -- потребляемая мощность ПЭВМ ( 0,2 кВт), t - время работы в день (16 часов),

Зэл = 0,2*0,2*16*365= 233,6 у.е.,

Норматив затрат на послегарантийный ремонт оборудования составит 5 % от стоимости оборудования. Тогда

Зр =4500*0,05 =225 у.е.

Затраты на оплату труда определим по формуле, табл. 3.3:

Зот = ( з/п+ з/п*Нд)* 12*Ч (6) Зот = (350+350*0,35)*12*2 = 11340 у.е.

Таблица 3.3. Исходные данные

Определим начисления на заработную плату: Li - отчисления в фонд социальной защиты населения (35%)

11340 *0,35 =3969 у,е.

- отчисления в соцстрах (1%)

11340 *0,01 =113,4 у.е.

Итого отчисления составят:

3969 +113,4 =4082,4 у.е.

Абонентская плата за доступ в Internet (256 Кбит-сек) с использованием IP-адреса будет равна:

3i = (60 + 1)*12= 732 y.e. Расходы на проводимую рекламную кампанию составят:

Зр= 45*12= 540 у.е.,

где 45 у.е. - расценки за размещение статьи в ленте новостей афиша сайта tut.by, 12 -количество месяцев. Расходы по доставке товара покупателю составят 400 у.е. Они включают заработную плату водителя, амортизацию автомобиля, стоимость топлива. За год расходы по данной статье составят 4800 у.е. Затраты на расходные материалы 150 у.е. Результаты расчета текущих затрат по статьям приведены в табл. 3.4.

Таблица 3.4. Текущие затраты

Расчет прибыли от работы ЭМ

Результат в стоимостном выражении выступает в виде экономии трудовых, материальных и финансовых ресурсов, получаемых от:

сокращения затрат на рекламу,

сокращения численности персонала,

сокращения документооборота,

сокращения расходов на канцелярские принадлежности,

увеличения объема продаж и т.д.

При расчете эксплутационных затрат установили, что расходы на рекламу электронного магазина составили 540 у.е. Затраты же на рекламу обычного магазина фирме обошлись в 8000 у.е. (при условии выхода полуминутного рекламного ролика по БТ 40 раз в течение года и размещение рекламы на транспорте (рекламное объявление в метро в течение 3 недель и реклама в троллейбусе в течение месяца)). Т.о., мы видим, что экономия затрат на рекламу составила: 8000-540=7460 у.е.

Рассчитаем экономию затрат на оплату труда за счет уменьшения численности работников. При расчете эксплутационных расходов мы установили, что затраты на оплату труда 3 работников составили 11340$, начисления на ФЗП - 4082,4 у.е. Итого: 11340-4082,4=7257,6 у.е..

Так как в традиционном магазине фирмы работают 4 человека, то за счет уменьшения численности работников на 1 человека получили следующую экономию затрат:

(11340-4082,4)/3= 2419,2 у.е.

При функционировании электронного магазина уменьшается документооборот, связанный, как правило, с осуществлением внешнеторговых операций. Опираясь на исследования, выяснилось, что уменьшение происходит в 15 раз. Т.к. стоимость комплекта документов на одну операцию составляет 12,5 у.е., а фирма в текущем году заключила 16 договоров на поставку товара, то экономия будет равна: (16+16/10)*12,5=221,76у.е.

При создании электронного магазина отпадает необходимость аренды помещения (30м -- 300* 12=3600у.е.), покупки кассового аппарата, необходимой мебели, создания витрины. Также существует экономия затрат на канцелярские принадлежности в размере 414 у.е. Величину дополнительной прибыли, полученной за счет увеличения объема продаж, рассчитаем исходя из данных, приведенных в табл. 3.5.

Таблица 3.5. Исходные данные

Прирост прибыли рассчитаем по формуле:

Ппр=Пед*Q*%ув/100% (7)

где Ппр-- прирост прибыли.

Ппр=75*1000*30/100%=22500 у.е. Общая экономия затрат сведена в табл. 3.6.

Таблица 3.6. Оценка результата составляющих прибыли от ЭМ

Т.о., мы имеем возможность сэкономить на текущих затратах 36614,96 у.е., т.е. практически получить на эту сумму дополнительную прибыль. Но в качестве экономического эффекта выступает лишь чистая прибыль, остающаяся в распоряжении предприятия, которая определяется по формуле:

Пч=П-(П*НП)/100% (8)

где НП - ставка налога на прибыль республиканская и местная

(24%+4%)

Пч=36614,96* 72%/100%=~36614 у.е.

Расчет экономического эффекта от работы ЭМ

При эксплуатации электронного магазина чистая прибыль в конечном итоге возмещает капитальные затраты. Однако полученные при этом суммы результатов (прибыли) и затрат по годам приводят к единому времени - расчетному году путем дисконтирования их ценности данного года. Для этого используется норма дисконта Е, равная приемлемой для инвестора норме дохода на капитал, т.е. уровню доходности инвестиционных средств, который может быть обеспечен при помещении их в банк, а не при использовании на данный проект.