Реферат: Базы данных и файловые системы - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Базы данных и файловые системы

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 182 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Базы данных и файловые системы Файловые системы Историческим шагом явился пе реход к использованию централизованных систем управления файлами . С точки зрения прикладн ой программы файл - это именованная область внешней памяти , в которую можно записывать и из которой можно считывать данные . Правила именования файлов , спосо б дос тупа к данным , хранящимся в файле , и ст руктура этих данных зависят от конкретной системы управления файлами и , возможно , от типа файла . Система управления файлами бе рет на себя распределение внешней памяти , отображение имен файлов в соответствующие ад р еса во внешней памяти и обеспе чение доступа к данным . Первая развитая файловая система была разработана фирмой IBM для ее серии 360. К насто ящему времени она очень устарела , и мы не будем рассматривать ее подробно . Заметим лишь , что в этой системе поддерж ив ались как чисто последовательные , так и ин дексно-последовательные файлы , а реализация во многом опиралась на возможности только поя вившихся к этому времени контроллеров управле ния дисковыми устройствами . Если учесть к тому же , что понятие файла в OS/360 было выбрано как основное абстрактное понятие , которому соответствовал любой внешний объект , включая внешние устройства , то работ ать с файлами на уровне пользователя было очень неудобно . Требовался целый ряд гром оздких и перегруженных деталями конструкций. Все это хорошо знакомо программистам среднего и старшего поколения , которые прош ли через использование отечественных аналогов компьютеров IBM. 1.1.1. Структуры файлов Дальше мы будем говорить о более современных организациях файловых систем . Начнем со ст руктур файлов . Прежде всего , практически во всех современных компью терах основными устройствами внешней памяти я вляются магнитные диски с подвижными головкам и , и именно они служат для хранения фа йлов . Такие магнитные диски представляют собо й пакеты магнит н ых пластин (поверхн остей ), между которыми на одном рычаге дви гается пакет магнитных головок . Шаг движения пакета головок является дискретным , и каж дому положению пакета головок логически соотв етствует цилиндр магнитного диска . На каждой поверхности цилинд р "высекает " дорожк у , так что каждая поверхность содержит чис ло дорожек , равное числу цилиндров . При ра зметке магнитного диска (специальном действии , предшествующем использованию диска ) каждая дорожк а размечается на одно и то же количес тво блоков таким обр а зом , что в каждый блок можно записать по максимуму одно и то же число байтов . Таким образом , для произведения обмена с магнитным диском на уровне аппаратуры нужно указат ь номер цилиндра , номер поверхности , номер блока на соответствующей дорожке и число ба й тов , которое нужно записать или прочитать от начала этого блока . Однако эта возможность обмениваться с магнитными дисками порциями меньше объема бло ка в настоящее время не используется в файловых системах . Это связано с двумя обстоятельствами . Во-первых , при выполнении об мена с диском аппаратура выполняет три ос новных действия : подвод головок к нужному цилиндру , поиск на дорожке нужного блока и собственно обмен с этим блоком . Из вс ех этих действий в среднем наибольшее вре мя занимает первое . Поэтому сущест в енный выигрыш в суммарном времени обмена за счет считывания или записывания только части блока получить практически невозможно . Во-вторых , для того , чтобы работать с ча стями блоков , файловая система должна обеспеч ить соответствующего размера буфера операт и вной памяти , что существенно услож няет распределение оперативной памяти . Поэтому во всех файловых системах явно или неявно выделяется некоторый базовый уровень , обеспечивающий работу с файлами , пред ставляющими набор прямо адресуемых в адресном пространств е файла блоков . Размер эти х логических блоков файла совпадает или к ратен размеру физического блока диска и о бычно выбирается равным размеру страницы вирт уальной памяти , поддерживаемой аппаратурой компью тера совместно с операционной системой . В некоторых ф айловых системах базо вый уровень доступен пользователю , но более часто прикрывается некоторым более высоким уровнем , стандартным для пользователей . Распрос транены два основных подхода . При первом п одходе , свойственном , например , файловым системам операцио н ных систем фирмы DEC RSX и VMS, пользователи представляют файл как последовател ьность записей . Каждая запись - это последовате льность байтов постоянного или переменного ра змера . Записи можно читать или записывать последовательно или позиционировать файл н а запись с указанным номером . Неко торые файловые системы позволяют структурировать записи на поля и объявлять некоторые поля ключами записи . В таких файловых с истемах можно потребовать выборку записи из файла по ее заданному ключу . Естественно , что в этом с лучае файловая с истема поддерживает в том же (или другом , служебном ) базовом файле дополнительные , неви димые пользователю , служебные структуры данных . Распространенные способы организации ключевых файлов основываются на технике хэширования и B-деревьев (м ы будем говорить об этих приемах более подробно в следующих лекциях ). Существуют и многоключевые способы организации файлов . Второй подход , ставший распространенным вм есте с операционной системой UNIX, состоит в том , что любой файл представляется как пос ле довательность байтов . Из файла можно прочитать указанное число байтов либо начина я с его начала , либо предварительно произв едя его позиционирование на байт с указан ным номером . Аналогично , можно записать указан ное число байтов в конец файла , либо п редвари т ельно произведя позиционирование файла . Заметим , что тем не менее скрытым от пользователя , но существующим во всех разновидностях файловых систем ОС UNIX, является базовое блочное представление файла . Конечно , для обоих подходов можно обес печить набор пре образующих функций , привод ящих представление файла к некоторому другому виду . Примером тому служит поддержание ст андартной файловой среды системы программировани я на языке Си в среде операционных си стем фирмы DEC. 1.1.2. Именование файлов Остановимся коро тко на спо собах именования файлов . Все современные файл овые системы поддерживают многоуровневое именова ние файлов за счет поддержания во внешней памяти дополнительных файлов со специальной структурой - каталогов . Каждый каталог содержи т имена каталогов и / и ли файлов , содержащихся в данном каталоге . Таким образ ом , полное имя файла состоит из списка имен каталогов плюс имя файла в катало ге , непосредственно содержащем данный файл . Ра зница между способами именования файлов в разных файловых системах состоит в т о м , с чего начинается эта цепоч ка имен . В этом отношении имеются два крайних варианта . Во многих системах управления ф айлами требуется , чтобы каждый архив файлов (полное дерево справочников ) целиком располагал ся на одном дисковом пакете (или логическо м дис ке , разделе физического дискового пакета , представляемом с помощью средств опер ационной системы как отдельный диск ). В эт ом случае полное имя файла начинается с имени дискового устройства , на котором уста новлен соответствующий диск . Такой способ име новани я используется в файловых систе мах фирмы DEC, очень близко к этому находятся и файловые системы персональных компьютеров . Можно назвать эту организацию поддержанием изолированных файловых систем . Другой крайний вариант был реализован в файловых системах оп ерационной системы Multics. Эта система заслуживает отдельного большо го разговора , в ней был реализован целый ряд оригинальных идей , но мы остановимся только на особенностях организации архива файлов . В файловой системе Miltics пользователи п редставляли в с ю совокупность каталогов и файлов как единое дерево . Полное им я файла начиналось с имени корневого ката лога , и пользователь не обязан был заботит ься об установке на дисковое устройство к аких-либо конкретных дисков . Сама система , выпо лняя поиск файла по ег о имени , запрашивала установку необходимых дисков . Таку ю файловую систему можно назвать полностью централизованной . Конечно , во многом централизованные файлов ые системы удобнее изолированных : система упр авления файлами принимает на себя больше рутинной раб оты . Но в таких системах возникают существенные проблемы , если кому-то требуется перенести поддерево файловой системы на другую вычислительную установку . Компроми ссное решение применено в файловых системах ОС UNIX. На базовом уровне в этих файловы х систем а х поддерживаются изолированны е архивы файлов . Один из этих архивов объявляется корневой файловой системой . После запуска системы можно "смонтировать " корневую файловую систему и ряд изолированных файловых систем в одну общую файловую систему . Технически э т о производится с по мощью заведения в корневой файловой системе специальных пустых каталогов . Специальный си стемный вызов курьер ОС UNIX позволяет подключит ь к одному из этих пустых каталогов к орневой каталог указанного архива файлов . Пос ле монтирования об щ ей файловой сис темы именование файлов производится так же , как если бы она с самого начала бы ла централизованной . Если учесть , что обычно монтирование файловой системы производится при раскрутке системы , то пользователи ОС UNIX о бычно и не задумываются об исходном происхождении общей файловой системы . 1.1.3. Защита фай лов Поскольку файловые системы являют ся общим хранилищем файлов , принадлежащих , воо бще говоря , разным пользователям , системы упра вления файлами должны обеспечивать авторизацию доступа к файла м . В общем виде п одход состоит в том , что по отношению к каждому зарегистрированному пользователю данно й вычислительной системы для каждого существу ющего файла указываются действия , которые раз решены или запрещены данному пользователю . Су ществовали попытк и реализовать этот п одход в полном объеме . Но это вызывало слишком большие накладные расходы как по хранению избыточной информации , так и по использованию этой информации для контроля правомочности доступа . Поэтому в большинстве современных систем управлен ия файлами применяется подход к защите файлов , впервые реализованный в ОС UNIX. В этой системе каждому зарегистрирован ному пользователю соответствует пара целочисленн ых идентификаторов : идентификатор группы , к ко торой относится этот пользователь , и его с о б ственный идентификатор в группе . Соответственно , при каждом файле хранится пол ный идентификатор пользователя , который создал этот файл , и отмечается , какие действия с файлом может производить он сам , какие действия с файлом доступны для других пользовател е й той же группы , и что могут делать с файлом пользователи других групп . Эта информация очень компактна , при проверке требуется небольшое количество действий , и этот способ контроля доступа удовлетворителен в большинстве случаев . 1.1.4. Режим мног опользова тельского доступа Последнее , на чем мы остановим ся в связи с файлами , - это способы их использования в многопользовательской среде . Если операционная система поддерживает многополь зовательский режим , вполне реальна ситуация , к огда два или более пользовател ей однов ременно пытаются работать с одним и тем же файлом . Если все эти пользователи со бираются только читать файл , ничего страшного не произойдет . Но если хотя бы один из них будет изменять файл , для коррект ной работы этой группы требуется взаимная синхр о низация . Исторически в файловых системах применялс я следующий подход . В операции открытия фа йла (первой и обязательной операции , с кот орой должен начинаться сеанс работы с фай лом ) помимо прочих параметров указывался режи м работы (чтение или изменение ). Ес ли к моменту выполнения этой операции от имени некоторой программы A файл уже находился в открытом состоянии от имени некоторой другой программы B (правильнее говорить "процес са ", но мы не будем вдаваться в термино логические тонкости ), причем существующий режим открытия был несовместимым с жел аемым режимом (совместимы только режимы чтени я ), то в зависимости от особенностей систе мы программе A либо сообщалось о невозможности открытия файла в желаемом режиме , либо она блокировалась до тех пор , пока прог рамма B не выполнит операцию закрытия файла . Заметим , что в ранних версиях файловой системы ОС UNIX вообще не были реализованы какие бы то ни было средства синхрон изации параллельного доступа к файлам . Операц ия открытия файла выполнялась всегда для любого сущес твующего файла , если данный пользователь имел соответствующие права доступ а . При совместной работе синхронизацию следов ало производить вне файловой системы (и ос обых средств для этого ОС UNIX не предоставля ла ). В современных реализациях файловых систем ОС UNIX по желанию пользователя подд ерживается синхронизация при открытии файлов . Кроме того , существует возможность синхронизации нескольких процессов , параллельно модифицирующих один и тот же файл . Для этого вве ден специальный механизм синхронизационных за х ватов диапазонов адресов открытого файла. Области применени я файлов После этого краткого экскурса в историю файловых систем рассмотрим возмо жные области их применения . Прежде всего , конечно , файлы применяются для хранения текст овых данных : документов , текс тов программ и т.д . Такие файлы обычно образуются и модифицируются с помощью различных текстовых редакторов . Структура текстовых файлов обычно очень проста : это либо последовательность записей , содержащих строки текста , либо посл едовательность байтов , сре д и которых встречаются специальные символы (например , симв олы конца строки ). Файлы с текстами программ используются как входные тексты компиляторов , которые в свою очередь формируют файлы , содержащие объектные модули . С точки зрения файловой системы , объек тные файлы также обладают очень простой структурой - последовательность з аписей или байтов . Система программирования н акладывает на эту структуру более сложную и специфичную для этой системы структуру объектного модуля . Подчеркнем , что логическая структур а объектного модуля неизвестна файловой системе , эта структура поддерживает ся программами системы программирования . Аналогично обстоит дело с файлами , фор мируемыми редакторами связей и содержащими об разы выполняемых программ . Логическая структура таких фай лов остается известной только редактору связей и загрузчику - программе операционной системы . Примерно такая же ситуа ция с файлами , содержащими графическую и з вуковую информацию . Одним словом , файловые системы обычно обеспечивают хранение слабо структурир ованной информации , оставляя дальнейшую структуризацию прикладным программам . В перечисленных выше случаях использования файлов это даже хоро шо , потому что при разработке любой новой прикладной системы опираясь на простые , с тандартные и сравнительно дешев ы е средства файловой системы можно реализовать т е структуры хранения , которые наиболее естест венно соответствуют специфике данной прикладной области. Потребности инфор мационных систем Однако ситуация коренным образом отличается для упоминавшихся в начале ле кции информационных систем . Эти системы главным образом ориентированы на хранение , выбор и модификацию постоянно существующей ин формации . Структура информации зачастую очень сложна , и хотя структуры данных различны в разных информационных системах , между н ими часто бывает много общего . На н ачальном этапе использования вычислительной техн ики для управления информацией проблемы струк туризации данных решались индивидуально в каж дой информационной системе . Производились необход имые надстройки над файловыми сис т емами (библиотеки программ ), подобно тому , как это делается в компиляторах , редакторах и т.д . Но поскольку информационные системы требу ют сложных структур данных , эти дополнительны е индивидуальные средства управления данными являлись существенной частью и нформационных систем и практически повторялись от одной системы к другой . Стремление выделить и обобщить общую часть информационных систем , ответственную за управление сложно структур ированными данными , явилось , на наш взгляд , первой побудительной причино й создания СУБД . Очень скоро стало понятно , что нев озможно обойтись общей библиотекой программ , реализующей над стандартной базовой файловой системой более сложные методы хранения данных . Покажем это на примере . Предположим , чт о мы хотим реализовать просту ю информа ционную систему , поддерживающую учет сотрудников некоторой организации . Система должна выполн ять следующие действия : выдавать списки сотру дников по отделам , поддерживать возможность п еревода сотрудника из одного отдела в дру гой , приема на работу н овых сотруд ников и увольнения работающих . Для каждого отдела должна поддерживаться возможность получ ения имени руководителя этого отдела , общей численности отдела , общей суммы выплаченной в последний раз зарплаты и т.д . Для каждого сотрудника должна подде р живать ся возможность выдачи номера удостоверения по полному имени сотрудника , выдачи полного имени по номеру удостоверения , получения инфо рмации о текущем соответствии занимаемой долж ности сотрудника и о размере его зарплаты . Предположим , что мы решили ос новыва ть эту информационную систему на файловой системе и пользоваться при этом одним файлом , расширив базовые возможности файловой системы за счет специальной библиотеки функц ий . Поскольку минимальной информационной единицей в нашем случае является сотру д ник , естественно потребовать , чтобы в этом файле содержалась одна запись для каждого сотрудника . Какие поля должна содержать так ая запись ? Полное имя сотрудника (СОТР _ИМЯ ), номер его удостоверения (СОТР _НОМЕР ), инфо рмацию о его соответствии занимаемой дол ж ности (для простоты , "да " или "не т ") (СОТР _СТАТ ), размер зарплаты (СОТР _ЗАРП ), номер отдела (СОТР _ОТД _НОМЕР ). Поскольку мы хотим ограничиться одним файлом , та же запись должна содержать имя руководителя отдела (СОТР _ОТД _РУК ). Функции нашей информационной системы требуют , чтобы обеспечивалась возможность многокл ючевого доступа к этому файлу по уникальн ым ключам (недублируемым в разных записях ) СОТР _ИМЯ и СОТР _НОМЕР . Кроме того , дол жна обеспечиваться возможность выбора всех за писей с общем значением СОТР _ОТ Д _НОМЕР , то есть доступ по неуникально му ключу . Для того , чтобы получить численн ость отдела или общий размер зарплаты , каж дый раз при выполнении такой функции инфо рмационная система должна будет выбрать все записи о сотрудниках отдела и посчитать соответст в ующие общие значения . Таким образом мы видим , что даже дл я такой простой системы ее реализация на базе файловой системы , во-первых , требует создания достаточно сложной надстройки для мн огоключевого доступа к файлам , и , во-вторых , вызывает требование сущес твенной избыточно сти хранения (для каждого сотрудника одного отдела повторяется имя руководителя ) и выпо лнение массовой выборки и вычислений для получения суммарной информации об отделах . Кр оме того , если в ходе эксплуатации системы нам захочется , наприме р , выдавать списки сотрудников , получающих заданную зарплату , то придется либо полностью просматривать файл , либо реструктуризовывать его , объявляя ключевым поле СОТР _ЗАРП . Первое , что приходит на ум , - это под держивать два многоключевых файла : СОТРУДНИКИ и ОТДЕЛЫ . Первый файл должен содержать поля СОТР _ИМЯ , СОТР _НОМЕР , СОТР _СТАТ , СОТР _ЗАРП и СОТР _ОТД _НОМЕР , а вто рой - ОТД _НОМЕР , ОТД _РУК , ОТД _СОТР _ЗАРП (общий размер зарплаты ) и ОТД _РАЗМЕР ( общее число сотрудников в отделе ). Большинство неудобств , перечисле н ных в предыду щем абзаце , будут преодолены . Каждый из фа йлов будет содержать только недублируемую инф ормацию , необходимости в динамических вычислениях суммарной информации не возникает . Но зам етим , что при таком переходе наша информац ионная система должна о бладать некото рыми новыми особенностями , сближающими ее с СУБД . Прежде всего , система должна теперь зн ать , что она работает с двумя информационн о связанными файлами (это шаг в сторону схемы базы данных ), должна знать структуру и смысл каждого поля (наприм ер , чт о СОТР _ОТД _НОМЕР в файле СОТРУДНИКИ и ОТД _НОМЕР в файле ОТДЕЛЫ означают од но и то же ), а также понимать , что в ряде случаев изменение информации в одно м файле должно автоматически вызывать модифик ацию во втором файле , чтобы их общее с одержимое было с огласованным . Например , если на работу принимается новый сотрудник , то необходимо добавить запись в файл СОТРУДНИКИ , а также соответствующим образом изменить поля ОТД _ЗАРП и ОТД _РАЗМЕР в записи файла ОТДЕЛЫ , описывающей отдел этого сотрудника . Понятие сог ласованности данных является ключевым понятие м баз данных . Фактически , если информационная система (даже такая простая , как в наш ем примере ) поддерживает согласованное хранение информации в нескольких файлах , можно говор ить о том , что она поддерживает базу данных . Если же некоторая вспомогательна я система управления данными позволяет работа ть с несколькими файлами , обеспечивая их с огласованность , можно назвать ее системой упр авления базами данных . Уже только требование поддержания согласованности данных в н ескольких файлах не позволяет обойтись библиотекой функций : такая система должна и меть некоторые собственные данные (метаданные ) и даже знания , определяющие целостность данны х . Но это еще не все , что обычно т ребуют от СУБД . Во-первых , даже в нашем примере неудобно реализовывать такие запрос ы как "выдать общую численность отдела , в котором работает Петр Иванович Сидоров ". Было бы гораздо проще , если бы СУБД по зволяла сформулировать такой запрос на близко м пользователям языке . Такие языки называются языками запросов к базам данных . Например , на языке SQL наш запрос можно было бы выразить в ф орме : SELECT ОТД _РАЗМЕР FROM СОТРУДНИКИ , ОТДЕЛЫ WHERE СОТР _ИМЯ = "ПЕТР ИВАНОВИЧ СИДОРОВ " AND СОТР _ОТД _НОМЕР = ОТД _НОМЕР Таким образом , при формулировании запроса СУБД позволит не задумываться о том , как будет выполняться этот запрос . Среди ее метаданных будет содержаться информация о том , что поле СОТР _ИМЯ является ключевым для файла СОТРУДНИКИ , а ОТД _НО МЕР - для файла ОТДЕЛЫ , и система сама воспользуется этим . Если ж е возникнет потребность в получении списка сотрудников , не соответствующих занимаемой должности , то достаточно предъявить системе запрос SELECT СОТР _ИМЯ , СОТР _НОМЕР FROM СОТРУДНИКИ WHERE СОТР _СТАТ = "НЕТ ", и система сама выполнит необходимый по лный прос мотр файла СОТРУДНИКИ , поскольку поле СОТР _СТАТ не является ключевым . Далее , представьте себе , что в нашей первоначальной реализации информационной системы , основанной на использовании библиотек расши ренных методов доступа к файлам , обрабатывает ся операци я регистрации нового сотрудника . Следуя требованиям согласованного изменения файлов , информационная система вставила новую запись в файл СОТРУДНИКИ и собиралась модифицировать запись файла ОТДЕЛЫ , но именно в этот момент произошло аварийное выключ ение пит а ния . Очевидно , что после перезапуска системы ее база данных будет находиться в рассогласованном состоянии . Потреб уется выяснить это (а для этого нужно явно проверить соответствие информации с файл ах СОТРУДНИКИ и ОТДЕЛЫ ) и привести информа цию в согласованн о е состояние . Наст оящие СУБД берут такую работу на себя . Прикладная система не обязана заботиться о корректности состояния базы данных . Наконец , представим себе , что мы хотим обеспечить параллельную (например , многотерминаль ную ) работу с базой данных сотру дников . Если опираться только на использование ф айлов , то для обеспечения корректности на все время модификации любого из двух файл ов доступ других пользователей к этому фа йлу будет блокирован (вспомните возможности ф айловых систем для синхронизации парал л ельного доступа ). Таким образом , зачисление на работу Петра Ивановича Сидорова сущес твенно затормозит получение информации о сотр уднике Иване Сидоровиче Петрове , даже если они будут работать в разных отделах . На стоящие СУБД обеспечивают гораздо более тонк у ю синхронизацию параллельного доступа к данным . Таким образом , СУБД решают множество п роблем , которые затруднительно или вообще нев озможно решить при использовании файловых сис тем . При этом существуют приложения , для к оторых вполне достаточно файлов ; прил ожени я , для которых необходимо решать , какой ур овень работы с данными во внешней памяти для них требуется , и приложения , для к оторых безусловно нужны базы данных.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
На вопрос: где бы вы хотели услышать фамилии всего руководства страны, большинство россиян ответили: на утренней перекличке в зоне.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "Базы данных и файловые системы", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru